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

Question

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

P.S. мои реальные модульные тесты (не те, которые используют насмешки) отбросят существующие таблицы, если структура базового объекта домена была изменена.

Answer 1

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

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

Таким образом, вопрос в том, имеет ли потенциалущерб / хлопоты / затраты на поддержку / финансовые затраты на потерянные записи в вашей базе данных перевешивают трудности разработки и тестирования?

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

Answer 2

Ваши проблемы в разработке не должны влиять на дизайн БД.Постоянное восстановление БД - это сценарий использования разработчиком, а не сценарий использования клиентом.

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

Answer 3

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

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

Answer 4

Может показаться, что вы можете рассчитывать на то, что ваши приложения будут следовать подразумеваемым правилам, но если вы не соблюдаете их, в конечном итоге кто-то совершит ошибку.
Или, может быть, через 5 лет кто-то сделает уборку старых записей, «которые больше не нужны», и не поймет, что в других таблицах все еще есть ссылки на них. Затем, через несколько дней / недель, вы или ваш преемник получите удовольствие от попыток исправить беспорядок, в который попала база данных. : -)

Answer 5

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

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

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

Answer 6

Вот хорошее обсуждение этого вопроса в предыдущем вопросе о SO: Что не так с внешними ключами? . [Изменить]: Аргумент заключается в том, чтобы сделать неиспользуемые внешние ключи, чтобы получить некоторые плюсы, если применимы какие-либо минусы.