Для чего нужна ORM?

Question

OlegTar @OlegTar

программист .NET, Javascript, Perl

Для чего нужна ORM?

Нет, я не пойму зачем заменять SQL язык своим?
Зачем надо делать класс, методы которого принимают имя таблицы, принимают условие для фраз WHERE, GROUP BY, HAVING.

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

Так в чём профит?

Вопрос задан более трёх лет назад
28266 просмотров

Комментировать

Подписаться 20 Оценить Комментировать

Решения вопроса 1

3 комментария

OlegTar @OlegTar Автор вопроса

Спасибо. Очень понятно. Понял, что ORM я путал с DBAL.

Написано более трёх лет назад
Алексей Скахин @pihel

Т.е. если я в своем проекте напишу функцию findAll(), которая возвращает все товары, то это уже можно считать ORM?

Написано более трёх лет назад
Вячеслав Плиско @AmdY

это даже не dbal, а паттерн builder, в данном контексте query builder, он не болько помогает обстагироваться от типа стораджа, но и собирать запрос по частям, например, с учётом if-оф и переданных параметров.

кстати. типичная ошибка — применения билдеров в контроллерах, а не в отдельном-классе модели.

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

$products = Products::findAll();
$category = $products[0]->get('Category');
$category['name'] = 'new name';
$category->save();

Написано более трёх лет назад

Пригласить эксперта

Ответы на вопрос 10

3 комментария

Zorkus @Zorkus

Да, и еще. Я ни слова не сказал тут о совместимости с разными СУБД, т.к. это часто ненужное требование. Большие и сложные системы активно использует СУБД-specific фичи, и требования писать скл-код, совместимый с Oracle/MSSQL/DB2 часто не ставится. Все понимают, что это — огромное усложноние и удорожение, далеко не всегда оправданная. Подлинная независимость от серьезного вендора — стоит дорого, очень дорого. А часто ли она реально нужна?

Написано более трёх лет назад
OlegTar @OlegTar Автор вопроса

Спасибо. Я понял, что ORM — это больше создание объектов, а не создание запросов. Я стараюсь выносить селекты в PL/SQL-ные пакеты.
А насчёт поддержки разных баз согласен, не нужно стремиться поддерживать разные базы.

Вообще по моему наблюдению складывается впечатление, что те, кто работал с Ораклом начинают относится к базе,
не как к простому хранилищу данных,
а те, кто не работал с Ораклом, относятся к базе данных как к простому хранилищу.

Может это из-за того, что нету авторов таких, как Том Кайт, для других баз данных.

Написано более трёх лет назад
Zorkus @Zorkus

Относиться к ораклу как к простому хранилищу :) Ну не знаю, какая аналогия вам ближе, это все равно что купить Hasselblad или хотя бы «однозначный» Canon снимать в автоматическом режиме. C Oracle нельзя работать, зная о базах данных столько, сколько знают средние, извинити меня ради бога, веб-разработчики.

Написано более трёх лет назад

5 комментариев

Melanitsky @Melanitsky

Вот пример почему это удобней. Часть метода с выборкой товаров с помощю ORM с условием.
/***/ $select = $db->select()->from('goods'); $select->join('pages', 'pages.idPage = goods.idPage'); if ($route) { $select->join('routing', 'pages.idRoute = routing.idRoute'); } if ($content) { $select->join('content', 'content.idContentPack = pages.idContentPack'); $select->where('content.idLang = ?', Kernel_Locale::getCurrent()->getId()); if ($search) { $select->where('content.contentName = ?', $search); } } if (!$expired) { $select->where('goods.goodExpirationDate > ?', time()); } if ($photo) { $select->join('photos', 'goods.idPhoto = photos.idPhoto'); } $select->where('pages.pageType = ?', self::TYPE_GOOD); if ($idCatalog) { $select->where('goods.idCatalog = ?',$idCatalog); } if ($idCategory) { $select->where('goods.idCategory = ?',$idCategory); } if ($idCity) { $select->where('goods.idCity = ?',$idCity); } /***/

Написано более трёх лет назад
aktuba @aktuba

Мог бы — поставил бы 10 плюсов!!! Реально, в последнее время orm/activerecord — скорее минус программисту, чем плюс. Ни разу еще не видел, чтобы от orm была реальная польза проекту. Экономия в 5-10 минут и потом 30-40 минут на переписывание модуля — такое встречаю уже довольно часто =(

Написано более трёх лет назад
kefirr @kefirr

Ересь какая-то, Linq являет собой практически тот же самый sql, от использования ORM ничего не меняется. Приглашаю к обсуждению: habrahabr.ru/qa/9097/#answer_38782

Написано более трёх лет назад
quantum @quantum

2Melanitsky, это разве orm? Это же конструктор запросов.

Написано более трёх лет назад
OlegTar @OlegTar Автор вопроса

Спасибо. А от Скрама польза всё-таки есть. Я работал по нём, главное всё по методологии делать.

Написано более трёх лет назад

5 комментариев

OlegTar @OlegTar Автор вопроса

нет. теперь понял.

Написано более трёх лет назад
sergei-grigorev @sergei-grigorev

Для поддержки нескольких СУБД можно использовать cayenne.apache.org/. Он поддерживает возможность писать запросы для каждой из поддерживаемых СУБД. Затем, сам определяет что за СУБД и подтягивает нужный запрос. Очень удобно, когда нужна максимальная производительность запросов (например, указание в запросах каки-то хинтов, индексов и т.д.)

Написано более трёх лет назад
sergei-grigorev @sergei-grigorev

Забыл написать, cayenne только для Java. Для других языков наверное есть «свои кайены». Как ORM мы его не используем, только для того, чтобы можно было писать запросы, учитывая синтаксис каждой из поддерживаемых СУБД

Написано более трёх лет назад
WebByte @WebByte

Это модификация единственного кажущегося более-менее адекватным ответа на вопрос: «При переходе проекта на новую СУБД не придется переписывать код». Правда, обычно его приводят как аргумент люди, которым не доводилось подобное действие совершать. Либо которые имеют слабое представление о возможностях той или иной СУБД.

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

SELECT id FROM foo ORDER BY bar;

SELECT /*+index_asc(foo_bar_id) */ FROM foo;

SELECT * FROM foo WHERE rownum <= 10;

SELECT * FROM ( SELECT f.*, rownum rn FROM foo f ORDER BY id ) WHERE rn <= 10;

SELECT f.*, row_number() over (ORDER BY id) rn FROM foo f HAVING rn <= 10;

Написано более трёх лет назад
Zorkus @Zorkus

+1!

Написано более трёх лет назад

Комментировать

3 комментария

ArtyV @ArtyV

Проще было написать, что нормальные ORM в нормальных языках упрощают поддержку проекта :)

Написано более трёх лет назад
WebByte @WebByte

Удалили поле из таблицы

Нормальная СУБД проверит зависимости и инвалидирует пакеты/процедуры.

Переименование поля

Переименование поля в СУБД, где SQL позволяет делать alias'ы вообще не понятно зачем нужно.

Не самая высокая оптимальность запросов через ORM частично компенсируется возможностью кэширования
Большинство СУБД кешируют и сами запросы, и данные, которые они возвращают. Не уверен, что разработчик средней руки реализует какой-нибудь LRU механизм лучше, чем разработчики СУБД.

переносимость на другие БД

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

Написано более трёх лет назад
Zorkus @Zorkus

Именно переименование делать приходится иногда — на одних алиасах и синонимах не всегда далеко уедешь.

Написано более трёх лет назад

Комментировать

2 комментария

Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации

Похожие вопросы

PHP

+3 ещё

Простой
Подключение к базе срабатывает через раз, где увидеть причину?
- 2 подписчика
- 07 апр.
- 120 просмотров
1

ответ
PHP

+2 ещё

Простой
Symfony OneToMany Fetch: Eager with ULID primary key?
- 1 подписчик
- 15 мар.
- 110 просмотров
1

ответ
PHP

+2 ещё

Простой
Как правильно смапить PHP класс с Doctrine?
- 1 подписчик
- 02 мар.
- 134 просмотра
0

ответов
Symfony

+1 ещё

Средний
Ошибка сохранения Entity с cascade в Doctrine в Symfony 5 — как избежать?
- 1 подписчик
- 09 февр.
- 63 просмотра
1

ответ
Регулярные выражения

+2 ещё

Простой
Как выбрать нужные таблицы в Symfony используя schema_filter?
- 1 подписчик
- 07 февр.
- 86 просмотров
1

ответ
PostgreSQL

+2 ещё

Простой
Подсоединиться к другой схеме Symfony — Doctrine?
- 1 подписчик
- 05 февр.
- 74 просмотра
2

ответа
Node.js

+2 ещё

Простой
По какой причине Prisma не хочет строить данный запрос?
- 1 подписчик
- 30 янв.
- 90 просмотров
2

ответа
Symfony

+1 ещё

Сложный
Из-за чего происходит ошибка при попытке создать миграцию в Symfony?
- 1 подписчик
- 08 янв.
- 97 просмотров
1

ответ
PHP

+1 ещё

Простой
Как сделать несколько вложенных джоинов?
- 1 подписчик
- 11 дек. 2023
- 89 просмотров
1

ответ
PHP

+2 ещё

Средний
Как создать свой ORM на PHP используя mysqli?
- 1 подписчик
- 08 дек. 2023
- 163 просмотра
1

ответ
Показать ещё Загружается…

Linkbuilder / Линкбилдер

WSS.media

До 80 000 ₽

Инженер по нагрузочному тестированию

Bell Integrator

До 250 000 ₽

Senior Java разработчик

Сбер • Москва

от 300 000 ₽

Верстка сайта

23 апр. 2024, в 11:46

3000 руб./за проект

Создать с нуля макеты для флаг-футбола: листовка А5, виндер-флаг, ролл

23 апр. 2024, в 11:44

1000 руб./за проект

Доработать приложение

23 апр. 2024, в 11:38

20000 руб./за проект

Answer 1 · 2011-07-02 12:59:37

Вы не путаете ORM с DBAL? ORM это не технология замены SELECT * FROM goods WHERE cost < 100.00 на $db->select()->from('goods')->where('cost < 100.00'). ORM это способ задания связи объектов и РСУБД. По сути позволяет абстрагироваться от способа хранения объектов вообще, с лёгкостью переходя от SQL к NoSQL, memcache, файлам или REST/RPC API на удалённом сервере, оперируя на уровне модели (если говорить о MVC и т. п.) простыми plain old objects, а их персистентность отдать контроллеру. Не $db->select()->from('goods'),, не mysql_query('SELECT * FROM goods'), а $goodsRepository->findAll(), а уж будет репозиторий формировать SQL запрос, читать файлы или память, а может стучаться на Гугл и парсить его вывод — его, репозитория, личное дело (а также разработчика(ов), отвечающих за подсистему хранения).

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

ORM это не только инструмент архитектурного разделения областей ответственности объектов и классов приложения, а также инструмент облегчения разделения труда разработчиков: кто хорошо шарит в SQL вообще и особенностях конкретного движка в частности — работает по «ту сторону» ORM, оптимизирует его как хочет, может нормализовывать и денормализовывать, например; кто хорошо разбирается в дебетах и кредитах — работает с plain old objects в терминах предметной области и может вообще ничего не зная об SQL, ему лишь нужно знать, что он всегда может получить объект или их коллекцию обратившись к методам вроде findById() или findAll() и сохранить результат работы методом save() или flush().

Answer 2 · 2011-07-03 10:28:34

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

Итак.
Представьте себе — у меня есть очень крупная система, и есть в ней таблица orders, в ней скажем, 50 колонок (на самом деле у нас 150, ну да ладно. Нормализаторы, молчать! Про нормальные формы я тоже знаю). И вот надо значит вам выбрать один ордер и показать его на экране. Допустим, вы пишете селект, неважно. Дальше что делать, в промежуточном слое? Вы не же вызываете хранимую процедуру (запрос) напрямую с, скажем, JSP страницы (я надеюсь), вам все равно надо получить данные и передать их как-то.
Так что, передавать их в виде массива, ArrayList-a, ассоциативного массива имя колонки/значения? Ну так дико громоздно, неудобно, и очень легко ошибиться. А если вам надо несколько ордеров, тогда что, создавать вложенные коллекции для конвертации результатов? Неудобно же.

Потому, очевидно, нам нужен объект Order, имеющий все нужные property, и нужен код, который умеет конвертировать результаты скл запрос в эти объекты (или коллекцию этих объектов).

Далее, очевидно, что писать руками _все_ запросы трудно и нудно, легко ошибиться, т.к. в Java они будут представляться в коде в виде строк (а значит, никакой статической типизации и compile-time проверок и прочее и прочее), и их надо держать либо в Java коде (если они мелкие), либо, если побольше, выносить в отдельные XML файлы.

В общем, ORM в больших проектах нужен для упрощения рутинной части. Без него — никуда :)

Безусловно, обойтись ТОЛЬКО ORM не получится. Есть у нас масса мест, где сложная логика написана в хранимых процедурах в 500-1000 строк на PL/SQL, написанная через ORM /Java она бы занимала в 10 раз больше и работала в 2 раза медленнее (при этом, она была бы еще и менее понятная, т.к. есть такая логика, которые в терминах реляционной алгебры описывается куда проще, чем в терминах ООП :), следовательно ложится на ORM со скрипом). Сколько нибудь сложные запросы с подзапросами, юнионами, хитрыми джойнами тоже писать через чистый ORM громоздко. Оптимизировать запросы, работающими в таблицах где, хотя бы, несколько сотен миллионов записей, без доступа к планам SQL оптимизатора и статистики/средствам мониторинга уровня СУБД тоже крайне сложно. Так что без SQL тоже — никуда :)

Answer 3 · 2011-07-02 00:34:45

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

Практической пользы от ORM в серьезных проектах чуть меньше, чем от какого-нибудь, прости, Господи, скрама.
В мелких — реальная польза лишь в том, что кто-то будет себя считать крутым ООП-программистом.

Как всегда, рекомендую статью:
citforum.ru/database/articles/vietnam/

Answer 4 · 2011-07-02 02:18:16

phasma @phasma

> Так в чём профит?

Вы пробовали поддерживать проект, который поддерживает 5-6 СУБД?

Ответ написан более трёх лет назад

5 комментариев

Answer 5 · 2011-07-02 00:29:33

некий интерфейс для работы с данными, которые не важно в каком виде и где находятся… в коде очень удобно работать с объектом, который представляет некоторый набор данных…

Answer 6 · 2011-07-02 09:33:17

Чтобы писать запросы на своём языке программирования, а не интегрировать в исходник ещё один язык.

Answer 7 · 2011-07-02 07:40:24

У меня в проекте есть много однотипных модулей, которые представляют объекты. Можно выбирать из базы один объект, можно выбирать много объектов. Всё это по любому полю или совокупности полей. И вот раньше приходилось на каждый такой модуль писать кучу однотипных запросов для всех этих действий. После внедрения ОРМ стоит только добавить несколько строк настройки в модуль и все эти методы сразу становятся доступны. То есть разработка становится быстрее за счёт устранения рутины. Совсем уж сложные запросы пишем, само собой на чистом SQL, а вот простые ORM выполняет на ура.

Answer 8 · 2011-07-03 13:33:13

Используем C#, DataObjects.Net
ORM с методолгией CodeFirst значительно упрощает поддержку БД.
Примеры:
1. Удалили поле из таблицы — нам нужно каким-то хитрым образом проверить все запросы которые могут использовать это поле. В случае работы через ORM мы уже на этапе компиляции не сможем написать неправильный запрос.
2. Переименование поля — при ORM можем пользоваться всеми возможностями таких штук как Resharper, и автоматом переименовывать там где надо.
3. Не самая высокая оптимальность запросов через ORM частично компенсируется возможностью кэширования на appserv, а так же возможностью выполнения части запросов на appserv (с учетом легкой масштабируемости последнего)
4. В качестве доп. бонуса, хотя и не особо используемого нами — получаем переносимость на другие БД

Answer 9 · 2011-07-02 00:30:47

Для простых запросов это удобней. Вы просто собираете запрос как конструктор, INSERT и UPDATE также невероятно удобен. Просто передать ассоциативный массив в качестве аргумента. По крайнем мере так в Zend_DB.
А сложные и вложенные запросы все ровно приходиться писать ручками.

Answer 10 · 2011-07-02 10:00:12

Что значит — зачем? Чтобы представлять результаты запросов в виде объектов языка. А как ещё вы предлагаете работать с результатами запросов?

Давайте предметно рассуждать. Покажите код, который делает запрос и показывает результаты пользователю. И посмотрим, можно ли этот код сделать лучше при помощи ORM.

PS Я работаю с Entity Framework 4.0, и он великолепен.

Answer 11 · 2011-07-03 12:56:21

Zorkus @Zorkus

написал статью тут — habrahabr.ru/blogs/programming/123293/

Ответ написан более трёх лет назад

2 комментария

Для чего нужна ORM?

Войдите, чтобы написать ответ

Минуточку внимания

Войдите на сайт