Это неверно: столбец может ссылаться на первичные ключи в разных таблицах, зависит от значения другого столбца?

Question

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

table video: (id, name, ...) 
table audio:(id, name, ...) 
table review_item(item_type, item_id, reason, ...) 

когда item_type='V', то item_id является идентификатор таблицы видео и когда item_type='A' затем item_id это идентификатор в таблице видео

Сочетание (item_type, item_id) является уникальным, но на самом деле он не является внешним ключом, вы не можете определить его как внешний ключ, поскольку он не указывает на одну таблицу. Синтаксис DDL не позволяет этого.

Может кто-нибудь узнать, какой принцип или правила нарушены здесь?

Answer 1

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

Основная проблема, с которой я столкнулся, заключается в том, что я не думаю, что БД могла бы обеспечить ограничение внешнего ключа на такой основе (возможно, это может быть через какое-то настраиваемое правило). То есть в MS SQL вы не могли бы ссылаться на первичный ключ других таблиц и обеспечить его соблюдение, и учитывая, что целостность - то есть принудительное ограничение ограничений - является одним из основных преимуществ FK, это будет моим главным аргументом. В зависимости от того, как работает ваш OR/Mapper (если вы его используете), я бы тоже поднял это. Он может не поддерживать принятую им стратегию.

Answer 2

Будет работать, но это указывает на другие возможные ошибки. Я мог думать о худших проектах. Обеспечение целостности было бы грубым.

Вы можете присоединиться, конечно, но вам нужно дополнительное условие в 'where', чтобы ограничить item_type.

Этот тип Arrangment вероятно указывает, что аудио и видео таблицы должны быть одной таблицы с другими столбцами, отличающих аудио/videoness и 1-1 ссылки на аудио или только видео только информацию, если вы получаете в такой джем. Но похоже, что много одинаковой информации - в реальном мире - относится к обоим. На самом деле, если бы видеозапись не содержала всю аудиоинформацию, это было бы не так, если бы это был тихий фильм :-) ??? Если применяется только одно, введите нули.

Это было бы легко, если бы вы могли использовать о-дб, верно? J/к ...

Answer 3

Смотрите этот пример того, как вы можете применять внешние ключи в этой ситуации: http://consultingblogs.emc.com/davidportas/archive/2007/01/08/Distributed-Keys-and-Disjoint-Subtypes.aspx

Колонка item_type нарушающего 2-е нормальной формы, но я думаю, что это нормально, потому что: А) Вы может легко реализовать ограничения CHECK, которые означают, что аномалии не могут возникнуть, B) это небольшая цена для оплаты, чтобы обеспечить очень полезное ограничение того, что элемент не может быть более одного типа. Большинство СУБД SQL не могут принудительно применять это правило декларативно, если вы не нажмете столбец типа в каждую таблицу.