Является ли сопоставление O/R?

Question

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

Answer 3

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

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