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

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

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

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

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

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

Answer 2

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

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

Answer 3

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

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