За и против программно осуществления внешнего ключа, чем в базе данных
Это доставляет такие неприятности с точки зрения разработки только путем разрешения базе данных, осуществляющей внешний ключ. Особенно во время модульного теста я не могу отбросить таблицу из-за внешнего ключа, ограничивает, я должен составить таблицу в таком порядке, что внешний ключ ограничивает предупреждение, не будет инициирован. В действительности я не вижу, что слишком много точки разрешения базе данных, осуществляющей внешний ключ, ограничивает. Если приложение было правильно разработано не должно быть никакого ручного управления базой данных кроме запросов Select. Я просто хочу удостовериться, что я не рою меня в дыру, не имея внешний ключ, ограничивает в базе данных и отъезде его только к ответственности приложения. Я пропускаю что-нибудь?
P.S. мои реальные модульные тесты (не те, которые используют насмешку) отбросят существующие таблицы, если структура базового объекта области была изменена.
6 ответов
По моему опыту, если вы не применяете внешние ключи в базе данных, то в конечном итоге (при условии, что база данных относительно большая и интенсивно используется) вы закончите с потерянными записями. Это может происходить по-разному, но кажется, что это происходит всегда.
При правильном индексировании внешних ключей не должно быть никаких преимуществ в производительности.
Итак, вопрос в том, перевешивают ли потенциальные убытки / проблемы / затраты на поддержку / финансовые затраты, связанные с потерянными записями в вашей базе данных, трудности разработки и тестирования?
По моему опыту, для бизнес-приложений я всегда использую внешние ключи. Чтобы ваши сценарии сборки работали правильно, это должна быть единовременная плата за установку, а стабильность данных с лихвой окупится в течение всего срока службы приложения.
Может показаться, что вы можете положиться на то, что ваши приложения будут следовать подразумеваемым правилам, но если вы не обеспечите их соблюдение, то рано или поздно кто-то допустит ошибку.
Или, может быть, через 5 лет кто-то проведет чистку старых записей, "которые больше не нужны", и не поймет, что в других таблицах есть данные, все еще ссылающиеся на них. Тогда через несколько дней/недель вы или ваш преемник получите увлекательную работу по устранению беспорядка, в который попала база данных :-)
Вот хорошее обсуждение этого вопроса в предыдущем вопросе на SO: Что не так с внешними ключами?. [Edit]: Аргумент заключается в том, чтобы сделать не принудительные внешние ключи, чтобы получить некоторые из плюсов, если применимы какие-либо минусы.
Смысл применения правил в базе данных заключается в том, что они декларативны - например, вам не нужно писать тонны кода, чтобы справиться с этим.
Что касается ваших модульных тестов, просто удаляйте таблицы в правильном порядке. Вам просто нужно написать функцию, чтобы сделать это правильно один раз.
Ваши проблемы в разработке не должны влиять на дизайн БД.Постоянное восстановление БД - это вариант использования разработчика, а не вариант использования клиентом.
Кроме того, ограничения БД помогают не только вашему приложению. Вы никогда не знаете, что может попытаться сделать ваш клиент. Не переусердствуйте, но вам нужно несколько.
Если приложение было правильно спроектировано, не должно быть никаких манипуляций с базой данных вручную, кроме , кроме выбора запросы
Что? Что за кулаид ты пьешь? Большинство приложений баз данных существуют для управления данными в базе данных, а не только для их просмотра. Как правило, вся цель приложения - добавлять новые заказы или создавать новые записи о клиентах, или документировать обращения в службу поддержки и т. Д.
Внешние ключи служат для целостности данных. Целостность данных имеет решающее значение для возможности использовать данные с любой надежностью. Базы данных без целостности данных бесполезны и могут привести к убыткам компаний. Это превосходит ваше эгоцентричное мнение о том, что FK не нужны, потому что они усложняют разработку для вас. Данные гораздо важнее вашего удобства при запуске тестов (которые могут быть записаны для учета FK).