ORM и ограничения базы данных

Question

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

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

Причина, по которой я спрашиваю, состоит в том, что ORM, которые я изучал, NHibernate и Linq to SQL, кажется, не очень хорошо работают при наличии уникальных ограничений базы данных. Например, удаление строки и повторная вставка строки с тем же бизнес-ключом приводит к исключению внешнего ключа. (Есть тонкие, также трудно избежать примеров.) ORM наблюдают ограничения первичного ключа и внешнего ключа, но, как правило, забывают об уникальных ограничениях.

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

Выполнение команд в правильном порядке нетривиально. Смотри мой вопрос здесь . Тем не менее, я ожидал лучшей поддержки распространенных случаев среди популярных ORM. Это кажется очень важным для внедрения ORM в существующую среду.

Каким был ваш опыт использования технологий ORM, освещает эти проблемы?

Answer 1

Это конечно ИМХО ...

ORM в целом рассматривает базы данных как простой носитель данных и ориентирован на поддержание ограничений / бизнес-логики на стороне «O», а не на стороне «R». Я не видел ни одного продукта ORM, в котором бы использовались некоторые из более «жестких» концепций реляционных баз данных, такие как альтернативные ключи, составные уникальные индексы и эксклюзивные подтипы. В некотором смысле ORM делает базу данных гражданином второго сорта.

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

Answer 2

Хорошие ORM, а NHibernate - один, обеспечит ссылочную целостность и правильное выполнение заказа, если база данных будет отображена правильно. Насколько я знаю, ни один из них не поддерживает проверку или уникальные ограничения. Проверочные ограничения - это бизнес-правила, которые должны применяться в бизнес-объектах. Обычно я применяю только критически важные бизнес-правила (т. Е. Бизнес теряет деньги и / или я теряю работу, если эти правила были нарушены) в базе данных, используя ограничения проверки и / или триггеры.

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

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

Вы пытались сделать это в рамках одной ISession? Я понял, что это проблематично.