Рекомендации по проектированию SQL: один столбец FK, много таблиц для ссылок

Question

У меня есть ситуация, когда у меня есть таблица с мягким внешним ключом для связи записей в таблице с одной из многих других таблиц в зависимости от другого значения в таблице. Для демонстрации:

TableOfTables: Id, TableName

HistoryTable: Id, TableOfTableId, NumberedTableId и т. Д ...

Таблица 1: идентификатор и т. Д. *

Таблица2: идентификатор и т. Д. *

Таблица3: идентификатор и т. Д. *

TableOfTables содержит запись для каждой пронумерованной таблицы в базе данных (Table1, Table2, Table3, ...). HistoryTable имеет внешний ключ к этой таблице (TableOfTableId). Он также имеет столбец NumberedTableId, который является ссылкой на столбец Id нумерованных таблиц.

Теперь это работает просто отлично, но между NumberedTableId и столбцами Id нумерованных таблиц нет ссылочной целостности. Теперь, насколько мне известно, вы не можете создать своего рода условный внешний ключ, который может указывать на разные таблицы в зависимости от какого-то условия ... так, как лучше всего получить здесь ссылочную целостность?

Единственное, о чем я могу думать, это иметь много столбцов NumberedTableId со значением NULL в столбце HistoryTable, каждый из которых имеет внешний ключ для конкретной таблицы с нумерацией, а остальные столбцы заполнены нулями ... безобразно или иметь отдельную HistoryTable для каждой нумерованной таблицы ... это будет означать множество HistoryTables, поскольку в нашей базе данных есть много нумерованных таблиц.

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

Какие у меня варианты здесь? Любое решение должно работать с Entity Framework 4.0.

Спасибо

Answer 1

На самом деле, есть три варианта (вы упомянули два, но я приведу их здесь)

1. Несколько столбцов FK с проверочным ограничением для обеспечения того, чтобы данная строка могла иметь только одно значение FK.
2. Несколько таблиц истории
3. Единая таблица истории с триггерами из ада для обеспечения ссылочной целостности (триггеры в исходных таблицах и в таблице истории).

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