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

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

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

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

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

Ответ 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 в представление, если хотите продолжить очистку этого кода.

EDIT: "Представление" в приведенном выше предложении означало просмотр RDBMS, а не просмотр в контексте MVC. Просто хотел прояснить любую путаницу.

Ответ 2

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

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

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

Ответ 3

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

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

Ответ 4

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

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

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

Ответ 5

В подобной ситуации я бы, вероятно, написал их вручную или использовал View (если в базе данных вы используете поддерживающие представления)

Ответ 6

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

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

Проблема с запросом через объекты домена/бизнес-объекты - это просто одна из характеристик.

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

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

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