Обнуляемые внешние ключи против реляционных таблиц для отношений N: M - PullRequest
4 голосов
/ 15 июня 2011

Я разработчик базы данных с экзистенциальным сомнением.

Если у вас есть таблица1, которая должна иметь отношение с таблицей2 или (исключая или, тем или иным) таблицей3,

  • какой подход и почему вы бы выбрали для высокой производительности чтения? enter image description here

Известно, что обнуляемые индексированные поля (опция A table1) являются плохим решением (см. O'Reilly High Performance MySQL, глава 3 или Руководство по MySQL ), но также известно, что соединение займет свое время выполнить (вариант B) ...

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

Заранее спасибо !!

Ответы [ 2 ]

5 голосов
/ 15 июня 2011

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

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

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

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

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

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

0 голосов
/ 22 июня 2011

На практике подходящий дизайн для производительности зависит от того, как «вес» ваши данные доступны.

Использование «Наследование таблиц» подходит для частого доступа к части данных (таблица2 или таблица3). Использование «Nullable FK» подходит, если ко всем данным (независимо от таблицы 2 или таблицы 3) часто обращаются.


«Nullable FK», однако, может быть установлен путем просмотра на основе «Table Inheritance».

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...