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

Question

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

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

Answer 1

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

Answer 2

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

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

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

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

Answer 3

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

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

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

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

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

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

Answer 4

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

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

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

Answer 5

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

Answer 6

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

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

Answer 7

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

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

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

Вопрос:

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

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

Answer 8

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

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

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

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

Answer 9

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

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

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

Answer 10

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

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