Действительно ли внешние ключи необходимы при проектировании базы данных?

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

Внешние ключи также могут помочь программисту написать меньше кода, используя такие вещи, как ON DELETE CASCADE . Это означает, что если у вас есть одна таблица, содержащая пользователей, а другая-заказы или что-то еще, то удаление пользователя может автоматически удалить все заказы, которые указывают на этого пользователя.

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

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

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

Схема базы данных без ограничений FK подобна вождению без ремня безопасности.

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

Вы бы приняли код в вашем приложении, который был бы таким небрежным? Это непосредственно обращалось к объектам-членам и непосредственно изменяло структуры данных.

Как вы думаете, почему это стало трудно и даже неприемлемо в современных языках?

Да.

1. Они держат тебя честным
2. Они держат новых разработчиков честными
3. Вы можете сделать ON DELETE CASCADE
4. Они помогают вам создавать красивые диаграммы, которые самостоятельно объясняют связи между таблицами

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

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

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

Edit: я хотел бы добавить, что, IMO, использование внешних ключей в поддержке on DELETE или ON UPDATE CASCADE не обязательно является хорошей вещью. На практике я обнаружил, что каскад при удалении должен быть тщательно рассмотрен на основе взаимосвязи данных - например, есть ли у вас естественный родитель-потомок, где это может быть OK или связанная таблица представляет собой набор значений поиска. Использование каскадных обновлений подразумевает, что вы разрешаете изменять первичный ключ одной таблицы. В этом случае у меня есть общее философское несогласие в том, что первичный ключ таблицы не должен меняться. Ключи должны быть по своей сути постоянными.

Предположим, что программист на самом деле уже делает это правильно

Создание такого предположения кажется мне крайне плохой идеей; в целом программное обеспечение феноменально глючит.

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

Хотя в идеальном мире естественные соединения будут использовать отношения (т. е. ограничения FK), а не совпадающие имена столбцов. Это сделало бы FKs еще более полезным.

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

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

Есть ли польза от отсутствия внешних ключей? Если вы не используете дерьмовую базу данных, FKs не так уж трудно настроить. Так почему же у вас есть политика избегать их? Одно дело иметь соглашение об именовании, которое говорит, что столбец ссылается на другой, и совсем другое-знать, что база данных действительно проверяет эту связь для вас.

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

Предположим, что программист действительно делает это уже в правильном порядке, тогда действительно ли нам нужна концепция внешние ключи?

Теоретически-нет. Тем не менее, никогда не было ни одного программного обеспечения без ошибок.

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

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

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

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

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

FKs очень важны и должны всегда существовать в вашей схеме, если только вы не eBay .

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

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

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

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

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

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

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

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

FKs позволяют DBA защитить целостность данных от неловкости пользователей, когда программист не может этого сделать, а иногда и защитить от неловкости программистов.

Предположим, что программист уже делает это правильно, тогда действительно ли нам нужна концепция внешних ключей?

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

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

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

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

Гораздо приятнее отлаживать ошибку ограничения FK, чем восстанавливать удаление, которое сломало ваше приложение.

Они важны, потому что ваше приложение-это не единственный способ манипулировать данными в базе данных. Ваше приложение может обрабатывать ссылочную целостность так честно, как оно хочет, но все, что требуется, - это один Бозо с правильными привилегиями, чтобы прийти и выдать команду вставки, удаления или обновления на уровне базы данных, и все ваши принудительные меры по обеспечению ссылочной целостности приложения будут обойдены. Установка ограничений FK на уровне базы данных означает, что, если этот бозон не решит отключить ограничение FK перед выдачей своей команды, ограничение FK приведет к сбою инструкции bad insert/update/delete с нарушением ссылочной целостности.

Я думаю об этом с точки зрения cost/benefit... в MySQL , добавление ограничения-это одна дополнительная строка DDL . Это всего лишь несколько ключевых слов и пара секунд размышлений. На мой взгляд, это единственный "cost"...

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

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

Вопрос:

Существуют ли какие-либо другие способы использования иностранных языков ключи? Может быть, я что-то упустил?

Он немного загружен. Вставляйте комментарии, отступы или имена переменных вместо "foreign keys"... Если вы уже прекрасно понимаете, о чем идет речь, то это "no use" для вас.

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

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

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

Альтернативный вариант-позволить ошибке проникнуть в систему (и при наличии достаточного времени это произойдет), где внешний ключ не задан и ваши данные становятся несогласованными. Затем вы получаете необычный отчет об ошибке, исследуете и "OH". База данных завинчена. Теперь, сколько времени это займет, чтобы исправить?

Внешние ключи можно рассматривать как ограничение, которое,

• Помощь в поддержании целостности данных
• Показать, как данные связаны друг с другом (что может помочь в применении бизнес-логики и правил)
• При правильном использовании может помочь повысить эффективность извлечения данных из таблиц.

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

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

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

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

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

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

В коде мы обычно просто получаем исключение, брошенное где-то , но в SQL мы обычно получаем ответы на "wrong".

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

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

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

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

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

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

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

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

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

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