Ссылочная целостность SQL между столбцом и (одной из многих возможных) таблиц

Question

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

Существует ли какой-то стандартный способ замены внешнего ключа чем-то, что может подтвердить, что идентификатор в столбце X моей таблицы счетов является существующим идентификатором в одной из многих таблиц записей операций?

Одна идея заключается в том, что при ведении журнала активности учетной записи я мог бы ссылаться на идентификатор операции, а также на операцию (в частности, на таблицу, в которой она находится) и использовать ограничение CHECK. Вероятно, это лучший путь, чтобы мой журнал не был неоднозначным.

Существуют ли другие способы решения этой проблемы, де-факто или проприетарные?

Решают ли нереляционные базы данных эту проблему?

EDIT:

Перефразируя мой начальный вопрос,

Существует ли несколько стандартный способ замены внешнего ключа чем-то, что может подтвердить, что идентификатор в столбце X в моей таблице фактур является существующим идентификатором в одной из многих (, но не обязательно во всех ) операциях таблицы записей?

Answer 1

Нет, это невозможно сделать с помощью одного столбца внешнего ключа.

Вы можете сделать одну из двух вещей:

• в вашей таблице, которая потенциально ссылается на любую из других x таблиц, имеет x ссылочных полей внешнего ключа (в идеале: идентификаторы типа INT), только одно из которых когда-либо будет не равно NULL Каждый ссылочный ключ FK ссылается точно на одну из ваших других таблиц данных

или

• иметь одну «дочернюю» таблицу на главную таблицу с правильной и принудительной ссылкой и собирать данные из этих n дочерних таблиц в представление (вместо таблицы) для отчетов / выставления счетов.

Или просто полностью забудьте о ссылочной целостности - что я бы определенно не рекомендовал!

Answer 2

Реализация таблицы наследования

см. Статью http://www.sqlteam.com/article/implementing-table-inheritance-in-sql-server

Answer 3

Альтернативой является применение сложных правил ссылочной целостности через триггер. Однако, если вы точно не знаете, какой у вас дизайн, обычно, когда задают такие вопросы, это обход плохого дизайна. Сначала посмотрите на проект и посмотрите, можете ли вы изменить его, чтобы сделать это чем-то, что можно обрабатывать с помощью FK, они гораздо более управляемы, чем такие вещи с помощью триггеров.

Если вы идете по маршруту триггера, не забывайте принудительно устанавливать обновления, а также вставки, и убедитесь, что ваш триггер будет работать правильно с многострочной вставкой и обновлением на основе набора.

Альтернативой дизайна является наличие таблицы amaster, которая является родительской для всех ваших таблиц с различными деталями, и использование FK против этого.