Жэкон,

честно говоря абсолютно не понял, что мешает использовать в таблицах вместо ключа непосредственно гуид. Зачем нужна отдельная таблица_с_гуидами?

Жэконв принципе ничего не мешает, но гуид строковый, места занимает поболее чем число, если все ссылки буду так указывать накладно получится
Во-первых - никакой он не строковый, а вполне себе бинарный. Ну и во-вторых- сделайте в объекте 2 поля - int и GUID. Связи внутри базы стройте по интам, а для синхронизации баз используйте гуид. А уникальность гуидов и так практически гарантирована.

Жэкона гуид в поле с каким типом хранить? а так идея ясна.
В некоторых СУБД есть специальный тип, а так - binary(16).
ЖэконКак быть с вопросом №2?. Не могу додумать как такие связки делать, фактически вместо 1 левого соединения надо организовать 2, причем в 1 поле. Можно с помощью "объединить" а можно левым вытащить 2 поля из разных таблиц и потом рассчитать третье, в котором будут данные из обоих таблиц, но это вообще печальный вариант.

У вас задача какая? Приведите постановку задачи, а не ваше представление о решении.

ЖэконЗадача примерна такова: реализовать в проектируемой БД возможность, в реквизитах объектов указывать ИД не из конкретной таблицы, а из произвольной. В примере выше ИД может указывать на табл2 или табл3.

Подобная фишка есть в 1с.

Вот как то так
Смысл в этом какой? Ваши разные таблицы - это подвиды одной сущности? Или так, по приколу?
PS В 1с много че есть, но в основном всякая хрень от безграмотности и последующей безысходности.

Жэконiljy :
Сущности разные, но имеют что то общее. В 1с это Наименование у справочников

Меня в общем то интересует организация такой техники, а именно не жесткой завязкой полей содержащих ключи на таблицы с данными, а динамической, позволяющей указывать разные объекты
Ради бога, вот вам сходу 2 варианта:
1. Наследование таблиц (классический)
Есть базовая таблица, содержащая ключевую информацию (ид, гуид, вид сущности) и общие для всех сущностей поля. На нее (по ид) ссылаются внешние ключи. Плюс для каждого вида сущности создается отдельная таблица, содержащая ид из основной + информацию, специфическую для конкретного вида.
2. Указание вида сущности непосредственно в ссылающейся таблице.
Применим, когда таких таблиц и типов сущностей очень немного (1-2-3), а от сущностей-потомков растет большая иерархия и лень городить триггеры на корректное удаление-изменение. В этом случае в ссылающейся таблице делается 2 поля данных (тип сущности, ид сущности), на которых создается несколько вычисляемых полей, которые и являются ВК на конкретные таблицы сущностей. При этом не NULL из них всегда только одно.

ЖэконДумаю он всяко лучше чем с кейсом. Или я не прав?
Вовсе не обязательно. Во-первых - тут никак не получится сделать ВК, соответсвенно никакой проверки целостности. А во-вторых - оптимизатор может на таких запросах себя вести не очень хорошо.

Жэкон,

и кстати, вместо case тут вполне подойдет coalesce.

ЖэконНасчет ВК это да казус, целостность организовать в программе можно.

Это порочный путь
Жэкон А может можно вьхами делать? Тогда и ВК получиться если я не ошибаюсь
Вьюхами делать что?

ЖэконМощность данных не очень большая, порядка 100 документов в день, иногда очень большие, с 1000 позиций, загрузка номенклатуры с характеристика, порядка несколько десятков тысяч. Аналогичных таблиц внешних в принципе не будет, некоторые могут иметь одинаковые поля.

Диапазонные автосчетчики честно говоря не знаю, но подозреваю что будут непонятные моменты по обмену даннымми между узлами

Вообще замысел, реализовать систему, с повышенной гибкостью, не такой как у 1с, но и не как у самописок. Нечто среднее. Где то упростить, где то организовать готовый функционал, чтобы в последствии оперативно работать. Первая задача организация структуры данных грамотная. На данный момент база 1с 10 гб, все нужно и все жалко удалять. Поэтому есть куда стремиться и развиваться.
Тогда воспользуйтесь старым правилом - не умножайте сущности без необходимости. По-русски еще говорят "не изобретайте велосипед". Вам нужна возможность хранить дополнительные данные, различные для экземпляров? Есть сразу 4 стандартных пути:
1. EAV
2. Наследование таблиц
3. XML-поля
4. SPARSE-поля

Это примерно в порядке убывания гибкости.
ЖэконВо вьюхе делать объединение. и на вьюху ВК цеплять. Или это тоже некашерно?

? И какая СУБД поддерживает такую чудную возможность??

ЖэконП-Л,

Вы тоже про ЕАВ говорите, неужели это панацея от всех проблем) буду читать про это.
Отнюдь, создает она проблем тоже прилично. Просто это очень гибкая система, но за все приходится платить.
ЖэконА вы как думаете лучше большие таблицы, или много мелких?
Все хорошо в меру. Работать с таблицей в 30000 полей ничуть не удобнее, чем с 10000 мелких таблиц по 10 полей.

ЖэконПочитал про ЕАВ, мне кажется это слишком, все таки по моему лучше значения (строки, числа, ключи) хранить в таблице объекта, а не распихивать все по разным таблицами. Такой подход должен быстродействие улучшить.

Быстродействие - улучшит. Но основное преимущество EAV как раз во всегда фиксированном числе таблиц фиксированной структуры и, как следствие, фиксированных запросах.

Жэкони к тому же ЕАВ как я понял не решит сути моего вопроса:

В одной таблице указан ключ на внешние таблицы (неважно как достигаем уникальность но она есть). Требуется левым соединением прицепить значения конкретного поля (в 2х табл одинаковое поле ) к первой таблицы в 1 поле (2 поля + case или сoalesce = результируеще поле, как варианты описали, но думаю ими не стоит злоупотреблять).
EAV решает задачу, а не воплощает ваше видение решения. Вы определитесь, чего вам больше хочется - задачу решить или сделать по-своему.

ЖэконЕще думаю можно например вынести общие поля (у всех справочников есть реквизиты номер, описание ...) в одну таблицу, но тогда во первых при обращении к маленькой части данных (выборка 1 справочника) потянуться куча левых данных (остальные справочники рядышком лежать будет). Это проблема хранилища, и для ее решения существуют индексы.
Жэкон во вторых это не решит проблему в корне, а лишь отчасти, т.к. позволит указыватье лишь объекты справочников, а не любые объекты системы.

Хотя в последнем возможно и нет необходимости.
По-моему вы явно нарушаете последовательность действий. У вас нет четкого представления о задаче, а вы уже за реализацию бьетесь. Ничего хорошего из этого не выйдет. Вам весь топик твердят, что надо сначала понять, что вы будете там хранить и что вы хотите с сохраненными данными делать.