Когда использовать ORM (Sequel, Datamapper, AR и т. Д.) Против чистого SQL для запросов

Question

Мой коллега в настоящее время разрабатывает SQL-запросы, подобные приведенным ниже, для создания отчетов, которые отображаются в файлах Excel через запрос внешних данных. В настоящее время требуются только процессы отчетности в БД (без операций CRUD).

Я пытаюсь убедить его, что было бы лучше использовать Ruby ORM, чтобы иметь возможность отображать данные в приложении rails / sinatra.

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

SQL-запросы, которые он пишет, явно довольно сложны, и, будучи относительно новым для SQL, он часто жалуется на то, что он очень трудоемкий и запутанный. Можно ли написать чрезвычайно сложные запросы с ORM? и если да, то что является наиболее подходящим (я слышал, что сиквел хорош для устаревших БД)? и каковы преимущества изучения ruby ​​и использования ORM по сравнению с использованием простого SQL при выполнении сложных запросов к базе данных?

Answer 1

Я сопровождающий DataMapper, и я думаю, что для сложных отчетов вы должны использовать SQL.

Хотя я и думаю, что когда-нибудь у нас будет DSL, обеспечивающий мощь и краткость SQL, все, что я до сих пор видел, требует от вас написания большего количества кода на Ruby, чем SQL для сложных запросов. Я бы предпочел поддерживать 5-строчный SQL-запрос, а не 10-15 строк кода Ruby, чтобы описать ту же сложную операцию.

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

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

class User
  include DataMapper::Resource

  property :id,   Serial
  property :name, String,  :length => 1..100, :required => true
  property :age,  Integer, :min => 1, :max => 130

  def self.some_complex_query
    repository.adapter.select <<-SQL
      SELECT ...
        FROM ...
       WHERE ...
       ... more complex stuff here ...
    SQL
  end
end

Тогда я могу просто сгенерировать отчет, используя User.some_complex_query. Вы также можете вставить SQL-запрос в представление, если хотите дополнительно очистить этот код.

РЕДАКТИРОВАТЬ: Под "представлением" в вышеприведенном предложении я имел в виду представление СУБД, а не представление в контексте MVC. Просто хотел прояснить любую потенциальную путаницу.

Answer 2

Если вы пишете свои запросы вручную, у вас есть возможность оптимизировать их. Когда я смотрю на этот запрос, я вижу некоторый потенциал для оптимизации (E.ICGROUPNAME LIKE '% san-fransisco%' или E.ICGROUPNAME LIKE '% bordeaux%' не будет использовать индекс = сканирование таблицы).

При использовании OR Mapper (нативных объектов / таблиц) для создания отчетов вы не имеете никакого контроля над результирующим SQL-запросом или не имеете его.

Но: Вы можете поместить этот запрос в View или Stored Процедуру и отобразить этот View / Proc с помощью OR Mapper. Вы можете оптимизировать свои запросы и , вы можете использовать все функции вашей платформы приложений.

Answer 3

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

ORM означает «объектно-реляционное отображение». Если у вас нет «O» (объектов), то это, вероятно, не подходит для вашего приложения. ORM действительно важен для сохранения объектов в базе данных и загрузки их из базы данных.

Answer 4

ORM расшифровывается как Object Relational Mapping, но, глядя на запрос, ваш друг, похоже, хочет получить довольно специфическую таблицу сумм и других элементов ... Я не использовал сиквел Ruby, но я использовал Hibernate и Python SQLAlchemy (для Django / Turbogears), и хотя вы можете выполнять такие запросы, я не верю, что в этом их сила.

Сила ORM заключается в способности находить отношения объектов Foo-> Bar, скажем, вы хотите, чтобы все объекты Bar для поля Foo были больше X ... Такого рода вещи. Поэтому я бы не классифицировал ORM как «хорошее» решение, хотя перешел бы на реальный язык программирования, такой как Ruby, и выполнял SQL вместо него ... это само по себе является победой.

Только мои 2 цента.

Answer 5

В такой ситуации я бы, вероятно, написал их от руки или использовал View (если используемая БД поддерживает представления)

Answer 6

ORM используются, когда у вас есть объекты (бизнес-объекты). Поэтому я предполагаю, что у вас есть приложение, с помощью которого вы создаете и управляете бизнес-объектами, которые в конечном итоге сохраняются в базе данных. Если у вас есть, то вы почти наверняка получили некоторое представление об отношениях и, возможно, многие из расчетов, которые вы собираетесь использовать в отчетах. Проблема с использованием SQL для прямого доступа к вашей базе данных для отчетов заключается в простоте обслуживания. Обычно вы прикладываете много усилий, чтобы ваши бизнес-объекты скрывали любые детали своей базы данных. Вы реализуете бизнес-правила и выполняете общие вычисления в своих бизнес-объектах. Создайте общий язык для всех членов команды и т. Д. И т. Д. Затем вы используете ORM для сопоставления с базой данных и для этого используете Habanero или NHibernate или что-то подобное. Это все замечательно. Мы делаем все это во имя ремонтопригодности и это здорово. Вы можете перенести свое приложение, изменить свой дизайн и т. Д. И т. Д.

Теперь вы идете и пишете SQL для запуска отчетов, в то время как у вас есть сотни отчетов. Во-первых, они часто дублируют логику, которая у вас уже есть в ваших BusinessObjects (обычно без каких-либо тестов), и еще хуже, Бхам Дамб, извините за удобство сопровождения, теперь забывают о перемещении этого поля из одной таблицы в другую, забывают о разбиении этой таблицы на две, меняя эти отношения и т.д. есть несколько отчетов, которые неожиданно прервутся.

Проблема с запросами через ваши доменные объекты / бизнес-объекты просто связана с производительностью.

В итоге, если вы используете концепцию доменного управления или бизнес-объект, попробуйте использовать их для отчетов. (Скорее всего, вы будете запускаться напрямую из БД с использованием SQL или хранимых процедур из соображений производительности, но попробуйте сначала ограничить их использование вашими бизнес-объектами, а затем использовать SQL). Другой вариант, конечно, заключается в использовании отдельной базы данных отчетов (как и некоторые концепции BI). Следовательно, отображение из вашей транзакционной базы данных в вашу базу данных отчетов находится в одном месте и может быть легко изменено в тех случаях, когда вы хотите изменить свой дизайн.

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

До тех пор, если вы используете Business Objects в своем приложении, попробуйте использовать их для создания отчетов, когда производительность является проблемой, прибегающей к SQL.