Целостность базы данных: управлять ею в БД или в App Logic? - PullRequest
0 голосов
/ 23 марта 2012

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

  1. Логика управления данными не «сразу видна», то есть это не тот код, к которому (по крайней мере) я привык.
  2. Сложно держать код БД под контролем исходного кода.

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

Каков «правильный путь» для этого? Существуют ли критерии выбора между хранением его в БД или на специальном слое вашего приложения?

1 Ответ

2 голосов
/ 23 марта 2012

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

Вы должны всегда определить это там. По сути, это ваша «последняя линия защиты» и гарантирует, что ни одно внешнее приложение не испортит ваши данные.

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

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

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

Вот две ссылки, показывающие некоторые примеры:
http://www.scarydba.com/2010/11/22/do-foreign-key-constraints-help-performance/
http://www.oracle.com/technetwork/issue-archive/2009/09-may/o39asktom-096149.html

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

...