Нужны ли внешние ключи в дизайне базы данных?

Question

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

Существуют ли другие варианты использования внешних ключей? Я что-то здесь упускаю?

Answer 1

Внешние ключи никогда не были явными (таблица (столбец) FOREIGN KEY REFERENCES), объявленная в проектах (бизнес-приложениях и веб-сайтах социальных сетей), над которыми я работал.

Но всегда существовало соглашение о присвоении имен столбцам, которые были внешними ключами.

Это похоже на нормализацию базы данных - вы должны знать, что вы делаете и что является следствием этого (в основном производительность).

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

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

Удаление всех заказов и счетов удаленного клиента с помощью ON DELETE CASCADE - прекрасный пример красивой, но неправильно спроектированной схемы базы данных.

Answer 2

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

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

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

2. Поддержка инструмента. Гораздо проще создавать модели данных с использованием Visual Studio 2008 , которые можно использовать для LINQ to SQL , если существуют правильные отношения внешнего ключа.

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

Answer 3

Да. ON DELETE [RESTRICT | CASCADE] не позволяет разработчикам прятать данные, обеспечивая чистоту данных. Недавно я присоединился к команде разработчиков Rails, которые не фокусировались на ограничениях базы данных, таких как внешние ключи.

К счастью, я обнаружил следующее: http://www.redhillonrails.org/foreign_key_associations.html - Плагины RedHill для Ruby on Rails генерируют внешние ключи, используя соглашение над конфигурацией . Миграция с product_id создаст внешний ключ для id в таблице products .

Проверьте другие замечательные плагины на RedHill , включая миграции, заключенные в транзакции.