Стоит ли O / R Mapping?

Question

Выразительность языков запросов (QL), предоставляемых с ORM, может быть очень мощной. К сожалению, после того, как у вас есть множество сложных запросов, а затем возникает какая-то загадочная схема или проблема с данными, очень трудно заручиться помощью нужного вам администратора БД? Вот они, часть команды, которая занимается разработкой базы данных, но они не могут прочитать QL приложения, а тем более предложить модификации. Я обычно заканчиваю тем, что извлекал сгенерированный SQL из журнала для них. Но тогда, когда они рекомендуют изменения к нему, как это относится к первоначальному QL? Процесс не туда и обратно.

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

Вопрос : Нашли ли вы способ решения проблемы двусторонней связи в вашей организации? Существует ли структура SQL-маршалинга, которая хорошо масштабируется и легко поддерживается?

(Да, я знаю, что чистый SQL может связать меня с поставщиком базы данных. Но * можно написать совместимый со стандартами SQL.)

Answer 1

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

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

Итак, короче говоря (да, коротко) да, ORM того стоит, но, как и любое решение проблемы, это не панацея.

Answer 2

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

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

Answer 3

Современные O / R-фреймворки, как я полагаю, вы знакомы, поддерживают опцию определения некоторых запросов вручную ((N) Hibernate делает). которые могут использоваться для сложных частей схем, а для простых частей использовать ORM, как это предусмотрено платформой.

еще одна вещь, которую вы должны проверить, может быть инфраструктура iBatis (http://ibatis.apache.org/). я не использовал ее, но я читал, что она ближе к SQL, и люди, знакомые с базами данных и SQL, предпочитают ее полноценный ORM-фреймворк, похожий на hibernate, потому что он ближе к ним, чем совершенно другая концепция ORM.