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

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

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

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

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

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

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

Обновлено: Я предполагаю, что он имел в виду ограничения внешнего ключа, а не внешние ключи как концепцию.

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

Алекс

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

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

Есть одна веская причина не использовать их: Если вы не понимаете их роль или как их использовать.

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

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

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

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

http://www.geekinterview.com/question_details/18869

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

Другими словами, они мог присоединились к таблицам с явными объявлениями (DRI), но они решил не.

Следовательно, база данных Clarify полна несоответствий и работает недостаточно эффективно.

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

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

@imphasing - именно такой образ мышления вызывает кошмары при обслуживании.

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

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

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

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

Я всегда ими пользуюсь, но потом делаю базы данных для финансовых систем. База данных - важная часть приложения. Если данные в финансовой базе данных не совсем точны, то на самом деле не имеет значения, сколько усилий вы вложили в свой код / ​​дизайн интерфейса. Вы просто зря теряете время.

Также существует тот факт, что несколько систем обычно должны напрямую взаимодействовать с базой данных - от других систем, которые просто считывают данные (Crystal Reports), до систем, которые вставляют данные (не обязательно с использованием разработанного мной API; он может быть написан тупой менеджер, который только что открыл для себя VBScript и имеет пароль SA для SQL-бокса). Если база данных не настолько защищена от идиотов, насколько это возможно, ну - пока, база данных.

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

Причины использования внешних ключей:

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

Причины не использовать внешние ключи:

• вы заставляете БД работать дополнительно при каждой операции CRUD, потому что она должна проверять согласованность FK. Это может стоить больших затрат, если у вас большой отток.
• принудительно устанавливая отношения, FK определяют порядок, в котором вы должны добавлять / удалять вещи, что может привести к отказу БД делать то, что вы хотите. (Конечно, в таких случаях вы пытаетесь создать осиротевшую строку, а это обычно не очень хорошо). Это особенно болезненно, когда вы выполняете большие пакетные обновления и загружаете одну таблицу перед другой, при этом вторая таблица создает согласованное состояние (но если вы делаете такие вещи, если есть вероятность, что вторая загрузка не удастся, а ваша база данных теперь несовместима?).
• иногда вы заранее знаете, что ваши данные будут грязными, вы принимаете это, и вы хотите, чтобы БД приняла это
• ты просто ленишься :-)

Я думаю (я не уверен!), Что большинство установленных баз данных предоставляют способ указать внешний ключ, который не применяется принудительно, а представляет собой просто бит метаданных. Поскольку неисполнение требований устраняет все причины не использовать FK, вам, вероятно, следует пойти по этому пути, если применима какая-либо из причин, указанных во втором разделе.

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

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

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

• ON DELETE RESTRICT - предотвращает удаление любых строк в другой таблице, которые имеют ключи в этом столбце. Это то, что Кен Рэй описал выше.
• ON DELETE CASCADE - Если строка в другой таблице удалена, удалите все строки в этой таблице, которые ссылаются на нее.
• ON DELETE SET DEFAULT - Если строка в другой таблице удалена, установите для всех внешних ключей, ссылающихся на нее, значение по умолчанию для столбца.
• ON DELETE SET NULL - Если строка в другой таблице удалена, установите для всех внешних ключей, ссылающихся на нее в этой таблице, значение NULL.
• ON DELETE NO ACTION - этот внешний ключ только отмечает, что это внешний ключ; а именно для использования в картографах OR.

Эти же действия применимы и к ON UPDATE.

По-видимому, значение по умолчанию зависит от того, какой сервер sql вы используете.

Для меня, если вы хотите следовать стандартам КИСЛОТА, критически важно иметь внешние ключи для обеспечения ссылочной целостности.

Я должен поддержать большинство комментариев здесь. Внешние ключи являются необходимыми элементами для обеспечения целостности ваших данных. Различные варианты ON DELETE и ON UPDATE позволят вам обойти некоторые из «падений», которые люди упоминают здесь относительно их использования.

Я обнаружил, что в 99% всех моих проектов у меня будут FK для обеспечения целостности данных, однако есть те редкие случаи, когда у меня есть клиенты, которые ДОЛЖНЫ хранить свои старые данные, независимо от того, насколько они плохи ... но потом я трачу много времени на написание кода, который в любом случае нужен только для получения достоверных данных, так что это становится бессмысленным.

Дополнительная причина использования внешних ключей: - Позволяет повторно использовать базу данных

Дополнительная причина НЕ использовать внешние ключи: - Вы пытаетесь привязать клиента к своему инструменту за счет сокращения повторного использования.

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

Я повторю то, что сказал Дмитрий, но добавлю по пункту.

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

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

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

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

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

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

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

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

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

Если, однако, у вас не было такого полного или положительного опыта в прошлом с усилиями, связанными с РСУБД, то вы, вероятно, не сталкивались с такой информацией. Или, возможно, ваше прошлое включает в себя погружение в среду, которая громогласно противилась базам данных (например, «эти администраторы баз данных - идиоты - мы мало, мы выбрали несколько разработчиков кода java / C#, которые спасут положение»), и в этом случае вы можете быть решительно против к загадочным лепетам какого-то слабака, говорящего вам, что FK (и ограничения, которые они могут подразумевать) действительно важны, если вы просто прислушаетесь.

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

Повторяю ответ Дмитрия - очень хорошо сказано.

Для тех, кого беспокоят накладные расходы на производительность, часто вызываемые FK, есть способ (в Oracle) получить преимущество оптимизатора запросов от ограничения FK без накладных расходов на проверку ограничений во время вставки, удаления или обновления. То есть создать ограничение FK с атрибутами RELY DISABLE NOVALIDATE. Это означает, что оптимизатор запросов ПРЕДПОЛАГАЕТ, что ограничение было применено при построении запросов, но база данных фактически не применяет ограничение. Здесь вы должны быть очень осторожны, чтобы взять на себя ответственность при заполнении таблицы с ограничением FK, подобным этому, чтобы быть абсолютно уверенным, что в ваших столбцах FK нет данных, которые нарушают ограничение, как если бы вы это сделали, вы может получить ненадежные результаты из запросов, которые включают таблицу, для которой установлено это ограничение FK.

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

Как и многие другие вещи, это компромисс. Вопрос в том, где вы хотите выполнить работу по проверке целостности данных:

(1) использовать внешний ключ (единственная точка для настройки таблицы, функция уже реализована, протестирована, доказала свою работоспособность)

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

Для базы данных более эффективно выполнять (2), проще в обслуживании и с меньшим риском (1).

Более важный вопрос: вы бы водили машину с завязанными глазами? Так будет, если вы создадите систему без ссылочных ограничений. Имейте в виду, что меняются бизнес-требования, изменяется дизайн приложения, соответствующие логические предположения в коде меняются, сама логика может быть подвергнута рефакторингу и т. д. В общем, ограничения в базах данных устанавливаются в соответствии с современными логическими предположениями, которые кажутся правильными для определенного набора логических утверждений и предположений.

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

К теме этого списка - внешний ключ сам по себе не «улучшает производительность» и не «снижает производительность» значительно с точки зрения системы обработки транзакций в реальном времени. Однако существует совокупная стоимость проверки ограничений в «пакетной» системе с ВЫСОКИМ объемом. Итак, вот разница между процессом транзакции в реальном времени и пакетной транзакцией; пакетная обработка - когда совокупная стоимость последовательно обрабатываемого пакета, связанная с проверками ограничений, снижает производительность.

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

ЗАПРОС ПРОИЗВОДИТЕЛЬНОСТИ - если таблицы объединяются по внешним ключам, помните о том, что столбцы внешнего ключа НЕ ИНДЕКСИРУЮТСЯ (хотя соответствующий первичный ключ индексируется по определению). Если на то пошло, индексируя внешний ключ, индексируя любой ключ, и объединение таблиц по индексированным помогает повысить производительность, а не объединение по неиндексированному ключу с ограничением внешнего ключа на нем.

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

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

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

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

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

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

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

Возьмите следующую таблицу

Адрес

• AddressId (PK)
• EntityId
• Тип объекта
• Город
• Состояние
• Страна
• Так далее..

Возможные значения EntityType могут быть Employee, Company, Customer, а EntityId относится к первичному ключу любой интересующей вас таблицы.

Я не думаю, что это лучший способ делать что-то, но в этом проекте он сработал.

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

Внешние ключи усложняют автоматическое тестирование

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

Однако accounts имеет внешний ключ для contracts, а contracts имеет fk для clients, clients имеет fk для cities, а cities имеет fk для states.

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

На это есть как минимум две возможные точки зрения:

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

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

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

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

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

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

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

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

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

Значение: бесхозные строки? Нет. Никогда в жизни такого не видел. Если только плохой программист не забыл внешний ключ или не реализовал это на другом уровне. Оба - в контексте Oracle - огромные ошибки, которые приведут к дублированию данных, потерям данных и, следовательно, к повреждению данных. Я не могу представить базу данных без принудительного FK. Мне это кажется хаосом. Это немного похоже на систему разрешений Unix: представьте, что все являются root. Подумайте о хаосе.

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

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

Quite часто получаем ошибки с Ограничения FK Невозможно добавить или обновить дочернюю строку: ограничение внешнего ключа не выполняется Предположим, есть две таблицы inventory_source и contract_lines, и мы ссылаемся на inventory_source_id в contract_lines из inventory_source, и предположим, что мы хотим удалить запись из inventory_source, и запись уже присутствует в contract_lines, или мы хотим удалить столбец PK из базовой таблицы, мы получаем ошибки для ограничений FK, мы можем избежать этого, следуя инструкциям ниже.

CREATE TABLE inventory_source (
inventory_source_id int(11) NOT NULL AUTO_INCREMENT,
display_name varchar(40) NOT NULL,
state_id int(11) NOT NULL,
PRIMARY KEY (inventory_source_id),
KEY state_id (state_id),
CONSTRAINT ba_inventory_source_state_fk FOREIGN KEY (state_id) REFERENCES   ba_state (state_id)
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8;

CREATE TABLE contract_lines(
contract_line_id int(11) NOT NULL AUTO_INCREMENT,
inventory_source_id int(11) NULL ,
PRIMARY KEY (contract_line_id),
UNIQUE KEY contract_line_id (contract_line_id),
KEY AI_contract_line_id (contract_line_id),
KEY contract_lines_inventory_source_fk (inventory_source_id),
CONSTRAINT contract_lines_inventory_source_fk FOREIGN KEY       (inventory_source_id) REFERENCES ba_inventory_source (inventory_source_id)
) ENGINE=InnoDB AUTO_INCREMENT=135 DEFAULT CHARSET=utf8 ;

Мы можем преодолеть это, используя следующие шаги: -

1. Удаление или обновление строки из inventory_source автоматически удалит или обновит соответствующие строки в таблице contract_lines, и это называется каскадным удалением или обновлением.
2. Другой способ сделать это - установить значение NULL для столбца т.е inventory_source_id в таблице contract_lines, когда соответствующая ему запись удаляется в таблице inventory_source.
3. Мы можем ограничить родительскую таблицу для удаления или обновления, другими словами, можно отклонить операцию удаления или обновления для таблицы inventory_source.
4. Попытка удалить или обновить значение первичного ключа не будет разрешена, если в указанной таблице есть соответствующее значение внешнего ключа.

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

Но вот еще одна очень хорошая реальная причина вообще не использовать внешние ключи:

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

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

Это может привести к разным проблемам:

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

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

Вы можете спросить: Кому нужны разные системы баз данных? Что ж, не каждый может себе позволить или хочет иметь полноценный SQL-сервер на своей машине. Это программное обеспечение, которое необходимо поддерживать. Другие уже вложили время и деньги в какую-то другую систему БД. Бессерверная база данных отлично подходит для небольших клиентов на одном компьютере.

Никто не знает, как ведут себя все эти системы БД, но ваша бизнес-логика с проверками целостности всегда остается неизменной.

«Перед добавлением записи убедитесь, что соответствующая запись существует в другой таблице» - это бизнес-логика.

Вот несколько причин, по которым вы не хотите, чтобы это было в базе данных:

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

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

3. TDD. В модульных тестах вы можете заменить базу данных на mocks и протестировать функциональность. Если у вас есть бизнес-логика в вашей базе данных, вы не проводите полные тесты, и вам нужно будет либо протестировать с базой данных, либо реплицировать бизнес-логику в коде для целей тестирования, дублируя логику и увеличивая вероятность того, что логика не работает так же.

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

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

Вот почему я редко использую Fks:

1. Большую часть времени я имею дело с огромными данными на небольшом сервере, чтобы повысить производительность, мне нужно удалить FK. Потому что, когда у вас есть FK и вы выполняете Create, Update или Delete RDBMS, сначала проверьте, нет ли нарушения ограничений и если у вас огромная БД, которая может быть чем-то фатальным 2. Иногда мне нужно импортировать данные из других мест, и поскольку я не слишком уверен в том, насколько они хорошо структурированы, я просто отбрасываю FK.

3. В случае, если вы имеете дело с несколькими БД, и наличие ссылочного ключа в другой БД не будет работать (на данный момент), пока вы не удалите FK (перекрестные отношения между базами данных)
4. Они также имели место, когда вы пишете приложение, которое будет размещаться в любой СУБД, или вы хотите, чтобы ваша БД экспортировалась и импортировалась в любую систему СУБД, в этом случае каждая конкретная система СУБД имеет свой собственный способ работы с FK, и вы будете наверное придется отказаться от использования FKs.

5. Если вы используете платформу РСУБД (ORM), вы знаете, что некоторые из них предлагают собственное отображение в зависимости от решения и технических особенностей своего предложения, и вам не нужно создавать таблицы и их FK. 6. Перед последним пунктом будет информация о работе с БД, которая имеет FK, и знания для написания приложения, которое выполняет всю работу без необходимости использования FK. 7. Наконец, когда я начал говорить, все зависит от вашего сценария, если знание не является препятствием. Вам всегда захочется использовать лучшее из лучшего, что вы можете получить!

Спасибо всем!