Что случилось с внешними ключами?

Исключение нулевого указателя генерируется, когда приложение пытается использовать null в случае, когда требуется объект. К ним относятся:

  1. Вызов метода экземпляра объекта null.
  2. Доступ или изменение поля объекта null.
  3. Принимая длину null, как если бы это был массив.
  4. Доступ или изменение слотов null, как если бы это был массив.
  5. Бросок null как будто это было значение Throwable.

Приложения должны бросать экземпляры этого класса, чтобы указать на другие незаконные использования объекта null.

Ссылка: http://docs.oracle.com/javase/8/docs/api/java/lang/NullPointerException.html

249
задан 9 revs, 5 users 34% 18 September 2018 в 22:58
поделиться

29 ответов

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

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

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

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

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

343
ответ дан 2 revs, 2 users 86% 23 November 2019 в 02:57
поделиться

Я имею к вторым самым большим комментариям здесь, Внешние ключи являются необходимыми объектами, чтобы гарантировать, чтобы у Вас были данные с целостностью. Различные варианты для НА УДАЛЯЮТ, и ON UPDATE позволит Вам обходить часть из "вниз падения", которые люди упоминают здесь относительно их использования.

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

1
ответ дан Mitchel Sellers 23 November 2019 в 02:57
поделиться

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

1
ответ дан 23 November 2019 в 02:57
поделиться

Я повторяю ответ Dmitriy - очень хорошо помещенный.

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

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

1
ответ дан Mike McAllister 23 November 2019 в 02:57
поделиться

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

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

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

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

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

1
ответ дан Eric 23 November 2019 в 02:57
поделиться

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

0
ответ дан Kilhoffer 23 November 2019 в 02:57
поделиться

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

0
ответ дан hamishmcn 23 November 2019 в 02:57
поделиться

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

1
ответ дан CodeRot 23 November 2019 в 02:57
поделиться

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

1
ответ дан Arno 23 November 2019 в 02:57
поделиться

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

РЕДАКТИРОВАНИЕ: Мое предположение, он обращался к ограничения внешнего ключа , не внешние ключи как понятие.

1
ответ дан 2 revs 23 November 2019 в 02:57
поделиться

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

1
ответ дан remonedo 23 November 2019 в 02:57
поделиться

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

, Если, однако, у Вас не было такого полного или положительного опыта в Вашем прошлом со связанными с RDBMS усилиями, тогда Вы не были, вероятно, подвергнуты такой информации. Или возможно Ваше прошлое включает погружение в среду, которая была крикливо антибазой данных (например, "те DBAs являются идиотами - мы немногие, мы выбранный, немного стропальщиков кода java/c# спасут положение"), в этом случае Вы могли бы быть сильно настроены против тайных бормотаний некоторого слабака, говорящего Вам, что FKs (и ограничения, которые они могут подразумевать) действительно важны, если Вы просто послушали бы.

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

80
ответ дан Ed Lucas 23 November 2019 в 02:57
поделиться

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

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

52
ответ дан 3 revs, 3 users 67% 23 November 2019 в 02:57
поделиться

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

41
ответ дан 3 revs 23 November 2019 в 02:57
поделиться

@imphasing - это - точно вид мышления, которое вызывает кошмары обслуживания.

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

14
ответ дан Ed Guiness 23 November 2019 в 02:57
поделиться

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

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

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

29
ответ дан Ant 23 November 2019 в 02:57
поделиться

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

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

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

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

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

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

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

2
ответ дан Ed Guiness 23 November 2019 в 02:57
поделиться

Существует одно серьезное основание не использовать их: , Если Вы не понимаете их роли или как использовать их.

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

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

12
ответ дан Kent Fredric 23 November 2019 в 02:57
поделиться

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

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

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

Эти те же действия также относятся ON UPDATE.

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

15
ответ дан 2 revs, 2 users 79% 23 November 2019 в 02:57
поделиться

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

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

3
ответ дан Dan 23 November 2019 в 02:57
поделиться

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

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

2
ответ дан Santiago Palladino 23 November 2019 в 02:57
поделиться

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

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

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

1
ответ дан Ken Ray 23 November 2019 в 02:57
поделиться

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

11
ответ дан Matt Rogish 23 November 2019 в 02:57
поделиться

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

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

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

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

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

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

который не имеет ограничений. Это не означает, что нет модели данных, да логической модели, но нет физической модели данных.

который не имеет ограничений. Это не означает, что нет модели данных, да логической модели, но нет физической модели данных.

4
ответ дан 23 November 2019 в 02:57
поделиться

Я повторю то, что Dmitriy сказал, но прибавление по точке.

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

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

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

0
ответ дан typicalrunt 23 November 2019 в 02:57
поделиться

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

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

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

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

0
ответ дан Jen A 23 November 2019 в 02:57
поделиться

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

Alex

-8
ответ дан Alex Fort 23 November 2019 в 02:57
поделиться

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

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

1. Большую часть времени я имею дело с огромными данными по маленькому серверу для улучшения производительности, я должен удалить FKs. Поскольку, когда у Вас есть FKs и Вы действительно Создаете, Обновление или Удаляете RDBMS, сначала проверяют, если там никакое ограничительное нарушение и если у Вас есть огромный DB, который мог бы быть чем-то фатальным

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

3. В случае, если Вы имеете дело с несколькими DBS и имеете ссылку, вводят другой DB, не будет подходить (что касается теперь), пока Вы не удаляете FKs (перекрестные отношения базы данных)
4. Они были также случаем, когда Вы пишете приложение, которое будет фиксироваться на любой RDBMS, или Вы хотите, чтобы Ваш DB был экспортирован и импортирован в любой системе RDBMS в этом случае, каждая определенная система RDBMS поступает по-своему контакта с FKs, и Вы будете, вероятно, обязаны отбросить использование FKs.

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

6. Прежде чем последняя точка будет знанием для контакта с DB, который имеет FKs и знание для записи приложения, которое делает все Задание без потребности FK 7. Наконец, поскольку я начал говорить, что все это зависит от Вашего сценария, в случае, если знание не является барьером. Вы будете всегда хотеть выполнить лучший из лучших, которые можно получить!


Благодарят Вас все!

0
ответ дан 23 November 2019 в 02:57
поделиться

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

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

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

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

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

0
ответ дан 23 November 2019 в 02:57
поделиться
Другие вопросы по тегам:

Похожие вопросы: