Добрый день!

Есть ли способ, ключами ораганизовать следующие ограничения:
В таблице "Dictionary", должно быть возможно внести GUID, который содержится хотя бы в одной из таблиц Table.
При этом, "table 1" и "table 2" всегда содержат не совпадающие GUID.

Как мне представляется, можно выключить ограничения внешнего ключа (или удалить его полность),
Добавить "Проверочные ограничения" в таблицу "Dictionary", а в table1 и 2 триггеры на удаление.

Или есть другой способ?

авторКонечно есть: слить table1 и table2 в одну table, тогда foreign key это всё что нужно.
Это конечно не вариант. Я привел простые таблицы.
А что если таблица1 - "Роли", таблица2 - "Пользователи"? сливать это в отду таблицу - значит сделать себе море проблем в запросах.

авторPS: Триггерами эту задачу не решить в принципе.
Функцилнальность "Проверочные ограничения" позволит запретить запись строк, проверяя наличие строки хотябы в одной таблице.
А триггеры на таблицу 1 и 2 нужны для того, чтобы обрабатывать удаление строк, удаляя чтобы при удалении они также были удалены из таблицы Dictionary.

авторМожно не полностью таблицы сливать, а вынести GUID + общие поля.
Я объясню чуть больше, зачем я спрашиваю :)
Представьте себе класс "TClass" и его наследника "TClassExt".
В нашем случае - объект класса "TClass" будет записан в таблицу 1.
Объект класса наследника "TClassExt" должен представлять собой другую таблицу, с теме же колонками + N количество новых (таблица 2).

Есть еще другой объект, который хранится в таблице dictionary, одно из полей которого, ссылка объект "TClass" или ссылка на объект наследника "TClassExt".

Слив таблиц не подходит еще потому, что имена колонок в "TClassExt" должны совпадать с "TClass".

авторПредставьте себе класс "TClass" и его наследника "TClassExt".
В нашем случае - объект класса "TClass" будет записан в таблицу 1.
Объект класса наследника "TClassExt" должен представлять собой другую таблицу, с теме же колонками + N количество новых (таблица 2).
На картинке имена колонок таблица 1 и 2 не совпадают, но на самом деле должны совпадать)
Еще в таблице 2 можно вообразить пару других колонок. Но сути вопроса про связи это не меняет.

А как такой вариант:
Создаем таблицу ссылок, состоящую из GUID и Варчара с именем таблицы откуда guid был заполнен.
К этой таблице цепляем таблицу 1 и 2. При добавлении записи в таблицу 1 или 2, guid будет дублироваться в таблице ссылок.
Из Dictionary можно ссылаться на таблицу ссылок вместо исходных таблиц.

авторК этой таблице цепляем таблицу 1 и 2.
PK будет в таблице ссылок.

авторКак это делается в системах управления базами данных (СУБД), в отличие от используемой Вами системы хранения и обработки данных (СХОД).
Есть объекты A, B, C, D, ... (в Вашем примере две таблицы - table1 и table 2 - очевидно, что их может быть сколько угодно, и они могут представлять различные типы сущностей, которые нельзя "сливать").
Создаем объект Ob и объявляем связи 1:1 этого объекта с каждым из объектов A, B, C, D...
Это похоже на то что я писал:
авторСоздаем таблицу ссылок, состоящую из GUID и Варчара с именем таблицы откуда guid был заполнен.
К этой таблице цепляем таблицу 1 и 2. При добавлении записи в таблицу 1 или 2, guid будет дублироваться в таблице ссылок.
Из Dictionary можно ссылаться на таблицу ссылок вместо исходных таблиц.

авторНе, ну можно ещё подкатегорию сделать не в ссылаемой сущности, а в ссылающейся.
Dictionary (dict_id, ...)
UserDictionary (dict_id, User_id, ...)
RoleDictionary (dict_id, Role_id, ...)
В целом похоже на мое предложение, только я PK к таблицам "UserDictionary" и "RoleDictionary" не указал.
Конечно они не будут лишними.

авторЭто -- полный бред.
Отличие от моего второго варианта только в наличии PK у таблиц UserDictionary и RoleDictionary.

авторИзбыточный. Не мелочись и перенеси в "таблицу ссылок" атрибуты (поля), общие у таблиц 1 и
2. Мой телепатер утверждает, что одна из таблиц при этом полностью опустеет и может быть
удалена. О чём тебе и твердят весь топик.
Таблица ссылок может содержать ссылки на сотни разных объектов.
Понятно, что можно в таблицу ссылок добавить общие поля.
Но все равно, не общие поля останутся в отдельных таблицах. И когда мне надо будет получить все поля объекта, я должен буду каждый раз соединяться с таблицей ссылок да еще выбирать из нее только те поля, которые относятся к выбираемому объекту.
Куда лучше, когда таблица у каждого класса своя, запросы проще и запутаться меньше шансов. Собственно, MasterZiv и Бредятина подтвердили что есть другой более удобный способ.