Я помню, как Джоэл Спольски упоминал в подкасте 014, что он почти никогда не использовал внешний ключ (если я правильно помню). Однако мне кажется, что они очень важны, чтобы избежать дублирования и последующих проблем целостности данных в вашей базе данных.
Есть ли у людей веские причины для этого (чтобы избежать обсуждения в соответствии с принципами)?
Редактировать: "У меня еще не было причины для создания внешнего ключа, так что это может быть моей первой причиной для его установки".
Причины использования иностранных ключей:
Причины не использовать иностранные ключи:
Я думаю (я не уверен!), Что большинство установленных баз данных предоставляют способ указать внешний ключ, который не применяется, и это просто немного метаданных. Поскольку неисполнение устраняет все причины, по которым не следует использовать FK, вам, вероятно, следует пойти по этому пути, если применима какая-либо из причин во втором разделе.
Это проблема воспитания. Если где-то в вашей образовательной или профессиональной карьере вы потратили время на кормление и заботу о базах данных (или работали в тесном контакте с талантливыми людьми, которые это сделали), тогда основные принципы сущностей и отношений хорошо укоренились в вашем процессе мышления. Среди тех рудиментов, как/когда/зачем указывать ключи в вашей базе данных (первичные, внешние и, возможно, альтернативные). Это вторая природа.
Если, однако, у вас не было такого тщательного или позитивного опыта в вашем прошлом, связанного с РСУБД, то вы, вероятно, не подвергались такой информации. Или, может быть, ваше прошлое включает погружение в среду, которая была критически анти-база данных (например, "эти администраторы - идиоты - мы малочисленны, мы выбрали малое число java/С# slingers для сохранения дня" ), и в этом случае вы могли бы решительно возражать к тайным болтовням какой-то dweeb, говорящей вам, что FKs (и ограничения, которые они могут подразумевать) действительно важны, если вы просто слушаете.
Большинство людей учили, когда они были детьми, что важно было чистить зубы. Можете ли вы обойтись без него? Конечно, но где-то по линии у вас будет меньше доступных зубов, чем у вас, если бы вы почистили после каждого приема пищи. Если бы мамы и папы были достаточно ответственны для разработки дизайна базы данных, а также для гигиены полости рта, у нас не было бы этого разговора.: -)
Я уверен, что есть много приложений, где вы можете сойти с рук, но это не лучшая идея. Вы не всегда можете рассчитывать на то, что ваше приложение будет правильно управлять вашей базой данных, и, честно говоря, управление базой данных не должно иметь большого значения для вашего приложения.
Если вы используете реляционную базу данных, то, похоже, в ней должны быть определены некоторые отношения. К сожалению, такое отношение (вам не нужны внешние ключи), похоже, поддерживается многими разработчиками приложений, которые предпочитают не беспокоиться о таких глупых вещах, как целостность данных (но это необходимо, потому что в их компаниях нет специализированных разработчиков баз данных). Обычно в базах данных, составленных этими типами, вам просто повезло иметь первичные ключи;)
Внешние ключи важны для любой модели реляционной базы данных.
Я всегда использую их, но затем я делаю базы данных для финансовых систем. База данных является важной частью приложения. Если данные в финансовой базе данных не совсем точны, то на самом деле не имеет значения, сколько усилий вы вкладываете в свой код/интерфейс. Вы просто тратите свое время.
Также существует тот факт, что несколько систем обычно должны напрямую взаимодействовать с базой данных - из других систем, которые только что считывают данные (Crystal Reports), в системы, которые вставляют данные (не обязательно используя API, который я разработал; написанный туповатым менеджером, который только что открыл VBScript и имеет пароль SA для блока SQL). Если база данных не является такой же идиот-доказательной, как может быть, хорошо до свидания базы данных.
Если ваши данные важны, то да, используйте внешние ключи, создайте набор хранимых процедур для взаимодействия с данными и сделайте самую сложную БД. Если ваши данные не важны, почему вы начинаете создание базы данных?
Обновление: теперь я всегда использую внешние ключи. Мой ответ на возражение "они усложняют тестирование" состоит в том, чтобы "написать свои модульные тесты, чтобы им вообще не нужна база данных. Любые тесты, использующие базу данных, должны использовать ее должным образом, включая внешние ключи. Если установка болезненная, найти менее болезненный способ сделать настройку. "
Предположим, вы используете внешние ключи. Вы пишете автоматический тест, который говорит: "Когда я обновляю финансовый счет, он должен сохранить запись транзакции". В этом тесте вас интересуют только две таблицы: accounts и transactions.
Однако у accounts есть внешний ключ к contracts, и у contracts есть fk для clients, и у clients есть fk для cities, а у cities есть fk для states.
Теперь база данных не позволит вам запустить тест без настройки данных в четырех таблицах, которые не имеют отношения к вашему тесту.
На это есть как минимум две возможные перспективы:
Также возможно временно отключить проверки внешнего ключа во время выполнения тестов. MySQL, по крайней мере, поддерживает это.
@imphasing - это именно тот вид мышления, который вызывает кошмары для обслуживания.
Почему бы вам игнорировать декларативную ссылочную целостность, где данные могут быть гарантированы как минимум согласованными в пользу так называемого "обеспечения программного обеспечения", который в лучшем случае является слабой превентивной мерой.
"Они могут сделать удаление записей более громоздким - вы не можете удалить" основную "запись, где есть записи в других таблицах, где внешние ключи нарушают это ограничение".
Важно помнить, что стандарт SQL определяет действия, которые предпринимаются при удалении или обновлении внешнего ключа. Те, о которых я знаю:
ON DELETE RESTRICT - предотвращает удаление любых строк в другой таблице, имеющих ключи в этом столбце. Это то, что Кен Рэй описал выше.ON DELETE CASCADE - Если строка в другой таблице удалена, удалите все строки в этой таблице, которые ссылаются на нее.ON DELETE SET DEFAULT - если строка в другой таблице удалена, установите любые внешние ключи, ссылающиеся на нее, по умолчанию для столбца.ON DELETE SET NULL - если строка в другой таблице удалена, установите для любых внешних ключей, ссылающихся на нее в этой таблице, значение null.ON DELETE NO ACTION - этот внешний ключ только отмечает, что он является внешним ключом; а именно для использования в мапперах. Эти же действия применимы и к ON UPDATE.
По умолчанию, похоже, зависит от того, какой сервер sql вы используете.
Есть одна хорошая причина не использовать их: Если вы не понимаете их роли или как их использовать.
В неправильных ситуациях ограничения внешнего ключа могут привести к дублированию аварийных ситуаций водопада. Если кто-то удалит неправильную запись, уничтожение ее может стать огромной задачей.
Кроме того, наоборот, когда вам нужно что-то удалить, если это плохо спроектировано, ограничения могут вызвать блокировку всех видов блокировок.
Нет хороших причин не использовать их... если только сиротские строки для вас не очень важны, я думаю.
Больший вопрос: будете ли вы ездить с завязанными глазами? То, как это происходит, если вы разрабатываете систему без ссылочных ограничений. Имейте в виду, что изменения бизнес-требований, изменения дизайна приложений, соответствующие логические допущения при изменении кода, сама логика может быть реорганизована и т.д. В общем, ограничения в базах данных создаются в соответствии с современными логическими предположениями, кажущимися правильными для определенного набора логических утверждений и предположений.
В течение жизненного цикла приложения референсные и проверки данных ограничивают сбор данных о полиции через приложение, особенно когда новые требования приводят к изменению логических приложений.
К теме этого листинга - внешний ключ сам по себе не "улучшает производительность" и не "значительно ухудшает производительность" с точки зрения системы обработки транзакций в реальном времени. Тем не менее, существует совокупная стоимость проверки ограничений в системе "пакетного" уровня HIGH. Итак, вот разница, процесс реального времени и пакетной транзакции; пакетная обработка - когда аггрефицированная стоимость, полученная с помощью проверок ограничений, последовательно обработанной партии создает поражение производительности.
В хорошо продуманной системе проверки целостности данных будут выполняться "до" обработки партии через (тем не менее, здесь также связана стоимость); поэтому во время загрузки не требуется проверка ограничений внешнего ключа. Фактически все ограничения, включая внешний ключ, должны быть временно отключены до тех пор, пока пакет не будет обработан.
QUERY PERFORMANCE - если таблицы соединены с внешними ключами, следует учитывать, что столбцы внешнего ключа НЕ INDEXED (хотя соответствующий первичный ключ индексируется по определению). Индексирование внешнего ключа, если на то пошло, путем индексации любого ключа, а объединение таблиц с индексированными помогает с лучшими характеристиками, а не путем присоединения к неиндексированному ключу с ограничением внешнего ключа на нем.
Изменение объектов, если база данных поддерживает только отображение/рендеринг содержимого/воспроизведения контента и т.д. и запись кликов, то для таких целей база данных с полными ограничениями для всех таблиц более убита. Думаю об этом. Большинство веб-сайтов даже не используют базу данных для таких целей. Для аналогичных требований, когда данные только записываются и не упоминаются для каждого слова, используйте базу данных в памяти, которая не имеет ограничений. Это не означает, что нет модели данных, да логической модели, но нет физической модели данных.
Дополнительные причины использования внешних ключей: - Позволяет больше использовать базу данных
Дополнительные причины НЕ использовать внешние ключи: - Вы пытаетесь заблокировать клиента в своем инструменте, уменьшив повторное использование.
Из моего опыта всегда лучше избегать использования FK в приложениях с критическими базами данных. Я бы не согласился с ребятами, которые говорят, что FK - хорошая практика, но ее не практично, где база данных огромна и имеет огромные операции CRUD/сек. Я могу поделиться без именования... один из крупнейших инвестиционных банков не имеет ни одного FK в базах данных. Эти ограничения обрабатываются программистами при создании приложений с использованием БД. Основная причина заключается в том, когда когда-либо выполняется новый CRUD, он должен выполнять несколько таблиц и проверять каждую вставку/обновление, хотя это не будет большой проблемой для запросов, затрагивающих отдельные строки, но это создает огромную задержку, когда вы имеете дело с которые любой крупный банк должен выполнять как ежедневные задачи.
Лучше избегать FK, но его риск должен решаться программистами.
"Перед добавлением записи проверьте, что соответствующая запись существует в другой таблице" - это бизнес-логика.
Вот несколько причин, по которым вы не хотите этого в базе данных:
Если бизнес-правила меняются, вам необходимо изменить базу данных. База данных потребуется во многих случаях воссоздать индекс, и это происходит медленно на больших таблицах. (Изменение правил включает в себя: позволяет гостям публиковать сообщения или разрешать пользователям удалять свою учетную запись, несмотря на то, что вы отправили комментарии и т.д.).
Изменение базы данных не так просто, как развертывание исправления программного обеспечения путем нажатия изменений в репозиторий. Мы хотим как можно больше избежать изменения структуры базы данных. Чем больше бизнес-логики в базе данных, тем больше вы увеличиваете шансы на изменение баз данных (и запуск повторной индексации).
TDD. В модульных тестах вы можете заменить базу данных на mocks и проверить функциональность. Если у вас есть какая-либо бизнес-логика в вашей базе данных, вы не выполняете полных тестов и вам необходимо либо протестировать базу данных, либо реплицировать бизнес-логику в коде для целей тестирования, дублируя логику и увеличивая вероятность того, что логика, не работающая в так же.
Повторное использование вашей логики с использованием разных источников данных. Если в базе данных нет логики, мое приложение может создавать объекты из записей из базы данных, создавать их из веб-службы, json файла или любого другого источника. Мне просто нужно поменять реализацию mapper и использовать всю мою бизнес-логику с любым источником. Если в базе данных есть логика, это невозможно, и вы должны реализовать логику на уровне карты данных или в бизнес-логике. В любом случае вам нужны эти проверки в вашем коде. Если в базе данных нет логики, я могу развернуть приложение в разных местах с использованием различных реализаций базы данных или плоских файлов.
Я согласен с предыдущими ответами в том, что они полезны для согласования данных. Однако несколько недель назад был интересный пост Джеффа Этвуда в котором обсуждались плюсы и минусы нормализованных и согласованных данных.
В нескольких словах денормализованная база данных может быть быстрее при обработке огромных объемов данных; и вам может не понравиться точная согласованность в зависимости от приложения, но это заставляет вас быть более осторожным при работе с данными, поскольку DB не будет.
База данных Clarify - это пример коммерческой базы данных, в которой нет первичных или внешних ключей.
http://www.geekinterview.com/question_details/18869
Самое смешное, что техническая документация имеет большое значение, чтобы объяснить, как связаны таблицы, какие столбцы использовать для их объединения и т.д.
Другими словами, они могли присоединиться к таблицам с явными объявлениями (DRI), но они выбрали не.Следовательно, база данных Clarify полна несогласованностей, и она отстает.
Но я полагаю, что это упростило работу разработчиков, не имея необходимости писать код для решения ссылочной целостности, такой как проверка родственных строк перед удалением, добавлением.
И это, я думаю, является основным преимуществом отсутствия ограничений внешнего ключа в реляционной базе данных. Это облегчает разработку, по крайней мере, с точки зрения дьявола.
Я знаю только базы данных Oracle, не другие, и могу сказать, что внешние ключи необходимы для поддержания целостности данных. Перед вставкой данных необходимо создать структуру данных и сделать ее правильной. Когда это будет сделано - и таким образом будут созданы все первичные И внешние ключи - работа будет выполнена!
Значение: осиротевшие строки? Нет. Никогда не видел этого в моей жизни. Если плохой программист не забыл внешний ключ, или если он реализовал это на другом уровне. Оба - в контексте Oracle - огромные ошибки, которые приведут к дублированию данных, сиротским данным и, следовательно, к повреждению данных. Я не могу представить базу данных без FK. Для меня это похоже на хаос. Это немного похоже на систему разрешений Unix: представьте, что все являются root. Подумайте о хаосе.
Внешние ключи важны, как и первичные ключи. Это как сказать: что, если мы удалим Первичные ключи? Ну, полный хаос случится. То, что. Вы не можете перенести ответственность основного или внешнего ключа на уровень программирования, он должен быть на уровне данных.
Недостатки? Да, конечно! Потому что на вставке будет сделано гораздо больше проверок. Но, если целостность данных важнее производительности, это не проблема. Проблема с производительностью в Oracle больше связана с индексами, которые поставляются с ПК и FK.
Они могут сделать удаление записей более громоздким - вы не можете удалить "главную" запись, где есть записи в других таблицах, где внешние ключи будут нарушать это ограничение. Вы можете использовать триггеры для удаления каскадов.
Если вы выбрали свой первичный ключ неразумно, то изменение этого значения становится еще более сложным. Например, если у меня есть ПК моей таблицы "клиенты" в качестве имени человека и сделайте этот ключ FK в таблице "заказы", если клиент хочет изменить свое имя, то это королевская боль. но это просто дряхлый дизайн базы данных.
Я считаю, что преимущества использования огневых ключей перевешивают любые предполагаемые недостатки.
Аргумент, который я слышал, заключается в том, что передним интерфейсом должны быть эти бизнес-правила. Внешние ключи "добавляют лишние накладные расходы", когда вы не должны допускать никаких вставок, которые в первую очередь нарушают ваши ограничения. Согласен ли я с этим? Нет, но это то, что я всегда слышал.
EDIT: Я предполагаю, что он имел в виду ограничения внешних ключей, а не внешние ключи как концепцию.
Проверка ограничений внешнего ключа занимает некоторое процессорное время, поэтому некоторые люди опускают внешние ключи, чтобы получить дополнительную производительность.
Я тоже слышал этот аргумент - от людей, которые забыли указать индекс на свои внешние ключи, а затем пожаловались, что определенные операции были медленными (потому что проверка ограничений могла использовать любой индекс). Итак, подведем итог: нет веских оснований не использовать внешние ключи. Все современные базы данных поддерживают каскадные удаления, поэтому...
Для меня, если вы хотите пойти по ACID, важно иметь внешние ключи для обеспечения ссылочной целостности.
Мне нужно вставить большинство комментариев в комментарии, внешние ключи - это необходимые элементы, чтобы обеспечить целостность данных. Различные опции ON DELETE и ON UPDATE позволят вам обойти некоторые "вниз падения", которые люди упоминают здесь в отношении их использования.
Я нахожу, что в 99% всех моих проектов у меня будет FK для обеспечения целостности данных, однако есть те редкие случаи, когда у меня есть клиенты, которые ДОЛЖНЫ хранить свои старые данные, независимо от того, насколько это плохо.... но потом я трачу много времени на написание кода, который входит, чтобы получить действительные данные в любом случае, поэтому он становится бессмысленным.
Как насчет ремонтопригодности и постоянства жизненных циклов приложений? Большинство данных имеют более длительный срок службы, чем приложения, которые его используют. Отношения и целостность данных слишком важны, чтобы оставить надежду на то, что следующая команда разработчиков получит это в коде приложения. Если вы не работали на db с грязными данными, которые не уважают естественные отношения, вы это сделаете. Тогда важность целостности данных станет очень понятной.
Я также думаю, что внешние ключи являются необходимостью в большинстве баз данных. Единственный недостаток (помимо достижения производительности, который приходит с принудительной согласованностью) заключается в том, что наличие внешнего ключа позволяет людям писать код, предполагающий наличие функционального внешнего ключа. Это никогда нельзя допускать.
Например, я видел, как люди пишут код, который вставляет в ссылочную таблицу, а затем пытается вставить в таблицу ссылок, не проверив, что первая вставка прошла успешно. Если внешний ключ будет удален позднее, это приведет к несогласованности базы данных.
У вас также нет возможности принять конкретное поведение при обновлении или удалении. Вам все равно нужно написать свой код, чтобы делать то, что вы хотите, независимо от наличия внешнего ключа. Если вы предполагаете, что удаленные объекты каскадируются, когда их нет, ваши удаления не удастся. Если вы предполагаете, что обновления для ссылочных столбцов распространяются на ссылочные строки, когда они их нет, ваши обновления не будут выполнены. Для написания кода вы также можете не иметь этих функций.
Если эти функции включены, ваш код будет имитировать их в любом случае, и вы потеряете небольшую производительность.
Итак, сводка.... Внешние ключи необходимы, если вам нужна согласованная база данных. Внешние ключи никогда не должны считаться присутствующими или функциональными в коде, который вы пишете.
Я повторяю ответ Дмитрия - очень хорошо поставленный.
Для тех, кто беспокоится о служебных нагрузках FK, которые часто возникают, есть способ (в Oracle), вы можете получить преимущество оптимизатора запросов от ограничения FK без затрат на издержку проверки ограничений во время вставки, удаления или обновления. То есть для создания ограничения FK с атрибутами RELY DISABLE NOVALIDATE. Это означает, что оптимизатор запросов ПРИНИМАЕТ, что ограничение было применено при построении запросов, без того, чтобы база данных фактически применяла ограничение. Вы должны быть очень осторожны, чтобы взять на себя ответственность, когда вы заполняете таблицу с помощью ограничения FK, как это, чтобы убедиться, что у вас нет данных в столбцах FK, которые нарушают ограничение, как если бы вы сделали это может получить недостоверные результаты от запросов, связанных с таблицей, в которой включено ограничение FK.
Обычно я использую эту стратегию для некоторых таблиц в моей схеме данных, но не в моей интегрированной промежуточной схеме. Я убеждаюсь, что таблицы, в которых я копирую данные, уже имеют одно и то же ограничение, или программа ETL принудительно применяет ограничение.
Многие из людей, отвечающих на вопросы, слишком зацикливаются на важности ссылочной целостности, реализованной с помощью ссылочных ограничений. Работа с большими базами данных с ссылочной целостностью просто не работает. Oracle кажется особенно плохим при каскадных ударах. Мое правило состоит в том, что приложения никогда не должны обновлять базу данных напрямую и должны выполняться через хранимую процедуру. Это сохраняет базу кода внутри базы данных и означает, что база данных сохраняет свою целостность.
Когда многие приложения могут обращаться к базе данных, проблемы возникают из-за ограничений ссылочной целостности, но это зависит от элемента управления.
Есть и более широкая проблема, что разработчики приложений могут иметь очень разные требования, которые разработчики баз данных могут не обязательно знать.
Если вы абсолютно уверены, что одна базовая система баз данных не изменится в будущем, я бы использовал внешние ключи для обеспечения целостности данных.
Но вот еще одна очень хорошая реальная причина не использовать внешние ключи вообще:
Вы разрабатываете продукт, который должен поддерживать разные системы баз данных.
Если вы работаете с инфраструктурой Entity Framework, которая может подключаться ко многим различным системам баз данных, вы также можете захотеть поддерживать безсерверные базы данных с открытым исходным кодом. Не все эти базы данных могут поддерживать ваши правила внешнего ключа (обновление, удаление строк...).
Это может привести к различным проблемам:
1.) При создании или обновлении структуры базы данных могут возникать ошибки. Возможно, будут только молчащие ошибки, потому что ваши внешние ключи просто игнорируются системой базы данных.
2.) Если вы полагаетесь на внешние ключи, вы сможете сделать меньше или даже не проверять целостность данных в своей бизнес-логике. Теперь, если новая система баз данных не поддерживает эти правила внешнего ключа или просто ведет себя по-другому, вы должны переписать свою бизнес-логику.
Вы можете спросить: кому нужны разные системы баз данных? Ну, не все могут себе позволить или хотят, чтобы на его машине был полностью раздутый SQL-сервер. Это программное обеспечение, которое необходимо поддерживать. Другие уже инвестировали время и деньги в какую-то другую систему БД. База данных без сервера отлично подходит для небольших клиентов только на одной машине.
Никто не знает, как все эти системы БД ведут себя, но ваша бизнес-логика с проверками целостности всегда остается прежней.
Я всегда думал, что лениво не использовать их. Меня учили, что это всегда должно быть сделано. Но тогда я не слушал дискуссию Джоэла. Возможно, у него была веская причина, я не знаю.
Один раз, когда FK может вызвать у вас проблему, вы имеете исторические данные, которые ссылаются на ключ (в таблице поиска), даже если вы больше не хотите, чтобы ключ был доступен.
Очевидно, решение состоит в том, чтобы лучше проектировать вещи, но я думаю о реальных ситуациях в мире, где вы не всегда можете контролировать полное решение.
Например: возможно, у вас есть таблица поиска customer_type, в которой перечислены различные типы клиентов - скажем, вам нужно удалить определенный тип клиента, но (из-за ограничений бизнеса) не могут обновить клиентское программное обеспечение, и никто эта ситуация возникает при разработке программного обеспечения, тот факт, что он является внешним ключом в какой-либо другой таблице, может помешать вам удалить строку, даже если вы знаете исторические данные, которые ссылаются на нее, не имеет значения.
После того, как вы сожгли это несколько раз, вы, вероятно, отвернулись от соблюдения законов.
(Я не говорю, что это хорошо, просто объясняя, почему вы можете вообще отказаться от запретов FK и db)