Дизайн базы данных: FK, которые являются NULL - хорошими или плохими?

Question

Предположим, у меня есть таблица «message», в которой я хочу сохранить все возможные сообщения, поддерживаемые моим приложением. Например, в FB-подобном приложении может быть «мультимедийное сообщение» (например, фото, видео, аудио), «сообщение мультимедийного альбома», «личное сообщение» и т. Д. Один из способов моделирования этого:

Table: message 
- messag_id (PK) 
- user_id (FK, this is the sender of the message) 
- message 

TABLE: media_message 
- media_message_id (PK, receiver of the message implied by the owner of the media) 
- message_id (FK) 

TABLE: media_album_message 
- media_album_message_id (PK, receiver of the message implied by the owner of the media album) 
- message_id (FK) 

TABLE: private_message 
- private_message_id (PK) 
- message_id (FK) 
- user_id (FK, receiver of the message) 

... etc. 

Итак, для каждого типа сообщения мне нужно создать какую-то «таблицу сопоставления».

Would что-то вроде этой работы:

TABLE: message 
- message_id (PK) 
- receiver_user_id (FK) 
- sender_user_id (FK) 
- message 
- media_album_id (FK, NULL allowed) 
- media_id (FK, NULL allowed) 

Я думаю, что с этим проектом, я все еще мог обеспечить целостность. Если media_album_id и media_id оба являются NULL, то я могу предположить, что это «личное» сообщение (или реализовать некоторую аналогичную логику в прикладном уровне). Нижняя сторона, если это даже нижняя сторона, состоит в том, что всегда будут столбцы, которые не используются. Опять же, возможно, это будет лучше масштабироваться - меньше СОЕДИНЕНИЙ и т. Д.

Мысли?

Answer 1

Плохо. Избегайте обнуляемых «внешних ключей». У них много недостатков.

Ограничение на строку ссылок не всегда выполняется, когда внешний ключ содержит нуль. Однако это поведение по умолчанию несовместимо между различными СУБД. Некоторые СУБД поддерживают параметры конфигурации, чтобы изменить поведение обнуляемых внешних ключей, а некоторые нет. Таким образом, разработчики SQL и пользователи могут быть неясны в отношении того, что на самом деле означает ограничение на неопределенное значение внешнего ключа с точки зрения целостности данных. Портирование базы данных между продуктами СУБД или даже между разными серверами с использованием одного и того же продукта может привести к непоследовательным результатам.

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

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

В логических терминах ограничение на неопределенность «внешнего ключа» не имеет большого логического смысла. Согласно стандарту SQL такое ограничение не может быть нарушено, даже если ссылка на таблицу пуста. Это противоречит одному из наиболее распространенных утверждений об использовании нулевого значения, которое представляет собой «неизвестный» случай. Если нет допустимых значений X, то любой «неизвестный» X, конечно, не может быть допустимым значением - и все же SQL это позволит!

И, наконец, это не нужно. Вы всегда можете построить таблицы так, чтобы нуль не нужен. Поэтому в интересах простоты и точности лучше оставить нули, чем помещать их.

Answer 2

FK - это установка ссылочного ограничения между двумя таблицами для обеспечения целостности данных. Скажем, что FK не может быть NULL. Если media_album_id & media_id имеют значение NULL, то они не должны быть FK.