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


94

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

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

+66

«Предположим, что программист на самом деле делает это правильно» - я даже не могу представить такой сценарий. 19 апр. 092009-04-19 15:05:38

+11

«Иностранный ключ» - это идея, а не технология. Это реляционное правило. Ваш вопрос действительно о том, следует ли пытаться обеспечить соблюдение правила в вашем коде или позволить базе данных помочь вам. Когда задействован параллелизм, лучше всего позволить механизму базы данных обеспечить соблюдение этого правила, поскольку он знает ВСЕ, что происходит в базе данных, в то время как ваш код не может быть осведомлен. 25 авг. 092009-08-25 18:20:01

  0

@ Трийнко, понятие внешних ключей не является реляционным правилом. 08 фев. 102010-02-08 12:21:33

  0

@Triynko - Чтобы расширить сказанное, внешние ключи не являются реляционным правилом, это правило * отношений * 12 фев. 102010-02-12 21:30:26

+5

@lubos & cdeszaq. На самом деле, это реляционное правило ... это подмножество правила 10 «Задворных заповедей Кодда» ... «Независимость целостности», в котором в основном говорится, что реляционная целостность РСУБД должна поддерживаться независимо от любого приложения, которое обращается к ней, что это то, что я объясняю легкомысленным способом. Это правило реализуется, помимо прочего, ограничениями внешнего ключа. Так что да, идея внешнего ключа - это «реляционное правило». 24 фев. 102010-02-24 22:01:31

  0

@ Трийнко, это зависит от меня, хочу ли я иметь ссылочную целостность между двумя отношениями или нет. Нигде не написано, что если у меня есть отношения с Клиентами и Счетами, я должен также иметь и поддерживать ссылочную целостность между ними. Я думаю, мы оба согласны с тем, что это хорошая идея для обеспечения ссылочной целостности там, где это применимо, но это просто хорошая идея, а не требование реляционной модели. 25 фев. 102010-02-25 12:46:27

+1

@lubos: Чтобы уточнить, вы говорите о том, собираетесь ли вы использовать определенную функцию, но я говорю о том, нужно ли присутствие этой функции иметь полную, полностью функциональную СУБД. Ссылочные ограничения, если и когда вы решите их использовать, - это что-то, что должно применяться в СУБД (а не в приложении), поэтому это функция должна быть там, и в этом смысле это требование реляционной модели, если вы собираетесь разработать полную СУБД. 01 мар. 102010-03-01 18:27:04

  0

Внешний ключ подобен удаленному первичному ключу. Когда у вас есть две связанные таблицы, внешний ключ связывает данные из отдельной таблицы, которые в противном случае были бы включены (избыточно) в исходную таблицу. Реляционная модель служит для устранения избыточности путем разделения данных на связанные таблицы, поэтому внешние ключи являются фундаментальными для реляционной модели. ИМО, если существует какое-либо отношение, тогда оно ДОЛЖНО применяться. Если вы решите не применять такое отношение, то IMO ваша база данных сосет :), не поддерживает полную запись событий и может в конечном итоге привести к повреждению вашего приложения с нулевыми значениями. 01 мар. 102010-03-01 18:38:56

  0

@ Трийнко, пожалуйста, не говорите, если вы имеете в виду отношение. это запутанно, потому что в реляционной модели отношение представляет собой набор кортежей, которые имеют один и тот же тип, а не отношения. также, когда вы говорите об устранении избыточности, вы не говорите о реляционной модели, вы говорите о нормализации базы данных или 3NF. реляционная модель должна придерживаться минимального набора правил, определенных в 1NF. ссылочная целостность, внешние ключи, устранение избыточности не являются правилами 1NF, поэтому они не являются правилами удовлетворения требований реляционной модели. надеюсь, теперь это имеет смысл. 02 мар. 102010-03-02 01:26:08

  0

@lubos: отношения и отношения - одно и то же. Что вам нужно понять, так это то, что отношение ограничивает два непересекающихся отношения (таблицы) в одно логическое отношение. Другими словами, отношения связаны с двумя отношениями, которые при правильном ограничении логически эквивалентны одному отношению. Когда вы пишете запрос JOIN, результатом является отношение SINGLE (таблица). То, что вы подразумеваете, заключается в том, что «реляционная модель» описывает базовую электронную таблицу, и я полностью не согласен. 02 мар. 102010-03-02 22:56:28

  0

Из Википедии «Реляционная модель»: «Реляционная модель» данных позволяет разработчику базы данных создавать последовательное логическое представление информации. Согласованность достигается путем включения * объявленных ограничений * в проект базы данных, который обычно называют * логическая схема *. Теория * включает в себя процесс нормализации базы данных *, посредством чего конструкция с некоторыми желательными свойствами может быть выбрана из набора * логически эквивалентных альтернатив *. 02 мар. 102010-03-02 22:57:07

  0

... продолжение: «Согласованность реляционной базы данных обеспечивается, а не правилами, встроенными в используемые ею приложения, а скорее ограничениями, объявленными как часть логической схемы и выполняемыми СУБД для всех приложений. , ограничения выражаются с использованием операторов реляционного сравнения, одним из которых является «подмножество» (⊆), теоретически достаточное.На практике ожидается, что будет доступно несколько полезных сокращений, наиболее важными из которых являются ключевые ключи кандидата (действительно, суперключи) и внешние ключи ». 02 мар. 102010-03-02 22:58:09

  0

Позвольте мне перефразировать« Что вы подразумеваете ... »следующим (поскольку редактирование, похоже, отключено): «То, что вы подразумеваете, - это ... что« реляционная модель »не охватывает идеи, связанные с поддержанием целостности отношения, когда это физически не пересекается для целей нормализации, но я думаю он охватывает это ». 02 мар. 102010-03-02 23:09:48

  0

Обратите внимание, что «правила» Codd не требуют ограничений ссылочной целостности, которые должны поддерживаться РСУБД. Правило 10 просто указывает, что ограничения целостности должны выполняться независимо друг от друга - он не говорит, какими ограничениями они должны быть. В любом случае «правила» не являются и никогда не должны были быть определением реляционной модели. Понятно, что база данных может быть реляционной без наличия в ней одного ограничения RI, а RDBMS может даже не поддерживать RI (просто у него, вероятно, не будет слишком много желающих клиентов). 31 мар. 112011-03-31 15:19:07

+2

Это часто встречается здесь. Я обвиняю [Joel Spolsky] (http://en.wikipedia.org/wiki/Joel_Spolsky) :-). Здесь есть много хороших ответов; вместо повторного ввода, я просто дам вам ссылку: http://stackoverflow.com/questions/83147/whats-wrong-with-foreign-keys 19 апр. 092009-04-19 15:02:54

95

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

+45

Если вам нужен индекс, создайте его, это не должно быть основной причиной для FK. (Фактически, в определенных обстоятельствах (например, больше вставок, чем выбирает), поддерживая FK, может быть медленнее.) 21 мар. 102010-03-21 17:28:57

+3

Это ужасный ответ. FKs genaerally может добавить дополнительные накладные расходы, не улучшая производительность. 13 фев. 152015-02-13 18:42:34

  0

В SQL-Server они не индексируются по умолчанию ни для рефери, ни для реферера. http://www.sqlskills.com/blogs/kimberly/when-did-sql-server-stop-putting-indexes-on-foreign-key-columns/ 27 июн. 162016-06-27 20:26:43

  0

Не в Oracle; вам нужно самостоятельно создавать индексы (в столбцах FK). 10 фев. 182018-02-10 20:17:01


55

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

+7

Хотя это, вероятно, должно быть обработано на уровне бизнес-логики. Решение о том, следует ли хранить связанные дочерние записи, не совсем то же самое, что гарантировать, что никакие ценности не нарушают отношения внешних ключей. 06 окт. 082008-10-06 21:38:42

+4

Другая проблема заключается в аудите, если аудит не выполняется на уровне db, каскадные обновления или удаления приведут к аннулированию вашего контрольного журнала. 01 сен. 092009-09-01 04:52:11

  0

@ Codewerks : Бизнес-логика может быть в БД. 01 фев. 112011-02-01 19:31:41

+2

@Greg Hewgill Это может привести к возникновению множества проблем. Вы должны быть очень осторожны, думая, что DELETE CASCADE, как и во многих случаях, вы хотите сохранить заказы, созданные пользователем при удалении пользователя. 20 авг. 082008-08-20 20:28:12


41

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

Это не требуется, строго говоря, но преимущества огромны.

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

+39

Джоэл: «До сих пор у нас не было проблем». До сих пор я никогда не вошел в фонарный столб. Но я все же думаю, что это хорошая идея носить ремни безопасности ;-) 04 ноя. 082008-11-04 10:36:18

+2

Может быть, у вас никогда не было проблемы, но может быть и там ... Большинство баз данных используют соглашение, такое как id_xxx, что точно такое же, что ixXXX 05 фев. 092009-02-05 21:54:59

+1

@Joel: Соглашения об именах вместо соблюдения правил? Мог бы также покончить с типом, пока вы на нем. 17 сен. 092009-09-17 20:54:16

+8

@ Эрик: Вы держите Fog Creek как своего рода аватар разработки программного обеспечения здесь. Если вы сказали: «У компании в Нью-Йорке нет внешних ключей в их дБ ...», мы все сказали бы «И?». 17 сен. 092009-09-17 20:56:08

+1

@jcollum, я сделал этот комментарий во время бета-тестирования Stack Overflow, когда почти все знали, кем были Джефф и Джоэл, и большинство из них, вероятно, слушали Podcast, так что Fog Creek был на всеобщем радаре. 18 сен. 092009-09-18 12:04:23

  0

@jcollum : кто-то сказал бы «И?», в то время как другие сказали бы «WTF?» (я только что сделал), но, я думаю, есть более чем один способ обрезать зуб. Приятно использовать «аватар», кстати. :) 01 май. 102010-05-01 00:17:29

+3

Eric: FogBugz использует соглашение об именах для внешних ключей. Например, ixBug понимается как индекс в первичный ключ таблицы Bug. До сих пор у нас не было проблем. - Joel Spolsky 13 фев. 122012-02-13 01:48:13

  0

«До сих пор у нас никогда не было проблемы». - Исправление: у вас никогда не было проблемы, которую ВЫ ЗНАЕТЕ - это еще одна отличная причина, позволяющая вашим инструментам помочь вам. 24 фев. 132013-02-24 23:47:50

  0

Чтобы ответить на реальный вопрос Эрика, я понимаю, что программное обеспечение Fog Creek размещено на серверах, контролируемых Fog Creek, а не программном обеспечении для сжатия, выпущенном в дикую природу. Это означает, что они * могут * гарантировать, что их база данных управляется только через их прикладное программное обеспечение. В этом контексте я предполагаю, что существует объектная модель, которая обеспечивает ограничения. 11 июн. 132013-06-11 01:28:33


8

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

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


1

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

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

6

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

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

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

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

+2

Это как лук. FKs - последний уровень защиты. Если это не встроенная локальная база данных, приложения, пытающиеся сделать ссылочную целостность, всегда плохая идея. 04 окт. 132013-10-04 19:23:08


12

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

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

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

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

+2

Хорошая точка, было бы неплохо соединить две таблицы с «ON [Relationship]» или другим ключевым словом и позволить db выяснить, какие столбцы задействованы.Кажется довольно разумным. 17 сен. 092009-09-17 20:58:04


12

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

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

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

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

+2

+1 Для ключей, являющихся постоянными, когда это возможно. 30 июл. 092009-07-30 16:04:07


20

Да.

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

Что значит честность? 06 сен. 152015-09-06 02:33:19

  0

Честный с концепцией, я думаю. Это мешает вам обманывать данные, выполняя быстрое и хромированное программирование. 08 янв. 172017-01-08 21:09:09


1

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

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

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

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

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

+1

Я работаю над системами, которые их не используют. И я сожалею об этом регулярно. Я видел больше случаев, когда могу подсчитывать нечувствительные данные, которые были бы предотвращены надлежащими ограничениями. 19 апр. 092009-04-19 15:15:25

  0

И, работая с иностранными ключами в нашем текущем проекте почти шесть месяцев, я полностью согласен с этим комментарием. 20 апр. 092009-04-20 13:17:03


4

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

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


1

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

В коде мы обычно получаем какое-то исключение, но в SQL мы обычно получаем «неправильные» ответы.

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

  0

Ограничения уникальности указывают на высокую мощность, которая используется оптимизатором при выборе механизма соединения. 22 дек. 092009-12-22 22:14:03


36

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

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

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

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

+2

+1 для хорошей аналогии между инкапсулированием и отношениями FK/PK. 17 сен. 092009-09-17 20:58:44


3

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

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

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

Вопрос:

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

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


1

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

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

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

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

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

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


8

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


0

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

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

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

  0

Ссылка не работает. 10 авг. 132013-08-10 19:38:47


5

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

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

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


8

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

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

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

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

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

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

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

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


4

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


5

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

ФКС позволяют DBA для защиты целостности данных от БОРМОТАТЬ пользователей, когда программист терпит неудачу сделать это, а иногда и для защиты от БОРМОТАТЬ программистов.

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

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

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

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

  0

Это отличный ответ. 23 мар. 132013-03-23 13:49:36


7

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

+1

хорошая ссылка там 01 дек. 092009-12-01 23:50:31

+2

эта ссылка на самом деле очень увлекательная ... мне действительно хотелось бы узнать больше деталей, и я немного боюсь использовать ebay сейчас. для других людей: нажмите на четвертый вопрос, чтобы узнать, что он говорит о своей структуре db. все интервью стоит посмотреть. также ... 'unibrow' 23 авг. 132013-08-23 18:52:31


2

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

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

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

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