Дизайн базы данных без внешних ключей

После работы с различными работодателями я заметил тенденцию "плохого" проектирования базы данных с некоторыми из этих компаний - прежде всего исключение ограничений внешних ключей. Меня всегда беспокоило, что в этих транзакционных системах не было FK, что способствовало бы ссылочной целостности.

Существуют ли какие-либо сценарии в транзакционных системах, в результате чего упущение FK было бы полезным?

Кто-нибудь еще испытал это, если да, то каков был результат?

Что делать, если они представлены с этим сценарием, и их попросили поддерживать/улучшать систему?

Ответ 1

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

Я испытал такие системы, и обычный результат - поврежденные данные, в том смысле, что существуют записи, которые не должны существовать (или наоборот). Это те системы, в которых люди считают, что они в порядке, потому что приложение позаботится об этом, не заботясь о том, что:

Каждое приложение должно заботиться о нем, а не о одном сервере БД.
Для каждого пользователя требуется только одна ошибка или злостное приложение.
Ответственность за защиту лежит на базе базы данных. Это одна из лучших возможностей.

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

Ответ 2

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

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

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

Ответ 3

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

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

Одна вещь, которая у меня есть, - это очень последовательное именование. В принципе, каждая таблица имеет первый столбец с именем ID, который точно совпадает с столбцом в других таблицах (или иногда с префиксом, когда между двумя объектами существует несколько отношений). Я также пытаюсь утверждать, что каждый столбец в такой базе данных имеет уникальное имя, которое описывает атрибут (поэтому "CustomerStartDate" отличается от "ProductStartDate" ).

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

Эти накладные расходы возникают во многих местах. При создании новой таблицы я могу использовать использование "create table as" или "select into" и не беспокоиться о деталях ограничений. При запуске обновления или вставки запросов я не хочу, чтобы накладные расходы базы данных проверялись на то, что я знаю. Однако я должен подчеркнуть, что последовательное именование значительно увеличивает мою уверенность в том, что все в порядке.

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

Ответ 4

В базе данных OLTP единственная причина, по которой я могу думать, - это заботиться о производительности больше, чем целостность данных. Принуждение FK, когда строка вставлена в дочернюю таблицу, требует поиска индекса в родительской таблице, и я могу представить, что могут быть экстремальные ситуации, когда даже этот относительно быстрый поиск индекса слишком велик. Например, очень интенсивное ведение журнала, где вы можете жить с неправильными записями журнала, и приложение, выполняющее запись, прост и вряд ли будет иметь ошибки.

Если вы можете жить с поврежденными данными, вы, вероятно, можете жить без базы данных.

Ответ 5

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

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

Производительность, вероятно, эквивалентна производительности, проистекающей из необходимости поддерживать целостность вне db.