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

Question

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

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

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

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