Чем отличается JDBC от ORM?

Question

[click_f]

В их их отличие и в каких случаях следует отдать предпочтение тому или иному подходу?

Answer 1

[Алексей Черемисин]

JDBC- интерфейс для sql-запросов. Работаете с голыми sql-запросами и оперируете таблицами, строками, колонками и значениями. Если результаты запроса нужно положить с объекты, то сами их туда распихиваете.
ORM - интерфейс для мапинга классов на таблицы, строки, колонки и значения базы данных. Работаете с java-объектами, sql-запросы за вас формирует ORM. Другими словами, не задумываетесь (почти), каксоставить sql-запрос, вытащить из него данные и раскидать значения по своим классам.
Предпочтительнее конечно работать с ORM, так как все за вас будет оптимизировано и закешировано. Конечно, нужно будет знать, не только как работает ваша база данных, но и как работает ваш ORM.

Answer 2

[Сергей Протько]

Для начала упростим JDBC до общего случая Data Access Object (DAO).

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

Словом, основная задача DAO - предоставить механизм работы с базой данных скрывая детали внутри себя.

ORM (Object-relational mapping) - это, если опять же упростить, общая идея конвертации "объектов" между системами с несовместимыми типами. Ну то есть как объекты из базы мэпятся на объекты.

Если под ORM брать мощные реализации вроде Hibernate, то тут становятся очевиднее минусы конкретно этой реализации. А именно - работать это будет эффективно когда вам нужно построить объектную модель логики приложения, нежели модель данных. Такие подходы хорошо работают в приложениях с реально сложной логикой, где вам бы хотелось в коде передать суть того, как все работает в реальности. Например как именно происходит автоматизация бизнес процесса. С реальными объектами и т.д.

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

Ну и в целом, ORM и DAO это весьма разные концепции, они о разных вещах. То есть у вас может быть использовано и ORM и DAO. Или ORM внутри использующее DAO... это не столь важно.

Comments

[Алексей Черемисин]

Извиняюсь, но у вас каша в голове.. 1) JDBC ну никак не упрощается до DAO, куда уж проще. 2) ORM не прологику приложения, а именно про модель данных приложения. 3) ORM в большинстве случаев работает очень эффективно, будь то база данных или xml. 4) для вещей типа генерации ответов ORM прекрасно подходит, даже на десятки тысяч объектов. 5) если вам нужно постоянно обновлять все значения в таблице, у вас фиговая модель базы данных и приложения. 6) и даже в этом случае проблем не вижу.

[Сергей Протько]

Алексей Черемисин:

1) окей, я упростил конкретную реализацию до подхода.
2) ORM не про модель данных, он тупо про мэппинги раз уж на то пошло. И я привел пример конкретной реализации - hibernate, оно не про модель данных, оно про объектную модель.
3) Повторюсь, оно работает эффективно при малом количестве объектов. Для вещей вроде сложных выборок их не стоит использовать. Вы же помните что сталось с идеей объектно ориентированных баз данных?
4) а потом мы удивляемся почему простая штука на java жрет гигабайты памяти.
5) очень конструктивно.
6) все записи в базе будут загружены в память, куча лишних действий, которые можно заменить одним вызовом метода в dao.

[Алексей Черемисин]

Сергей Протько: session.evict(), sesssionFactory.getCache().evictXXX() и statelessSessions решают практически все проблемы с массивными выборками. Ну и на всякий случай - koenserneels.blogspot.ru/2013/03/bulk-fetching-wit...
Ну также можно базу убить и слишком большим sql-запросом, а потом еще пол часа ждать отката транзакций и разблокировки полей/таблиц, и пусть весь мир подождет.
С другой стороны можно и в dom загнать 10 гигабайтный xml с таким же результатом по памяти, а можно и через sax пройтись. Так что если уж про хибернейт, его нужно уметь готовить, как впрочем и все остальное, когда что-то за 10к объектов перещелкивает.
По поводу п5, в большинстве виденных мной случаев это было именно так!

[Сергей Протько]

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

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

Не нужно просто зацикливаться и ставить "что-то по дефолту". Это всегда приводит не не самым эффективным решениями.

[Алексей Черемисин]

Сергей Протько: когда-то я был уверен, что программируя на ассемблере драйвера для os-9, я поступаю правильно. Это продолжалось ровно до тех пор, пока фирма microware не выпустила оптимизирующий компилятор ultra-c. Я просто взглянул на тот ассемблерный код, который он делал из си, такие конструкции с постфиксами, предикатами и косвенной адресацией мне и в страшном сне не снились. А практически полностью перестал писать на ассемблере, когда начал программировать под PPC, там сам ассемблер сделан для автоматической трансляции. Потом я некоторое время писал sql под всяко разно, а потом был хибернейт... И да, я таки взглянул на тот sql, который из него выходил, у меня тут же возникла аналогия! Компиляторы очень часто делают код гораздо лучше, чем человек, просто им надо в этом помогать. И конечно же, если без SQL или ассемблера не обойтись, то руки не нужно себе выворачивать, просто таких случаев стало катастрофически мало!

[Алексей Черемисин]

Сергей Протько: еще пример, давайте абстрагируемся от явы и хибернейта, вот совсем. Возьмем например руби, питон, го,, нодеджиэс, да тот же пехапе. Весь мир, за редким исключением отдельных индивидов пользуется ORM и не жалуется, пишут все начиная от бложиков и заканчивая системами типа портала госуслуг, и стараются о чистом sql не думать!

[Алексей Черемисин]

Сергей Протько: все руководства по быстрому старту к популярным web-фреймворкам начинаются со слов: ставим базу данных, создаем класс, определяем поля и вуаля! Где здесь, черт возьми dao и sql?!

[Сергей Протько]

Алексей Черемисин: в этом и проблема.

Подавляющее количество реализаций ORM в других языках базируется на active record, окей можно сделать row data gateway на базе оного и жить. В Python есть sqlalchemy, в ruby datamapper, в php есть Doctrine. Для nodejs я вообще не видел вменяемой реализации ORM, обычно все весьма примитивно.

Я видел как разработчики тратили день на задачу, которая при помощи dao решается за пол часа. Как они боролись с ограничениями ORM при помощи тех же кешей и тд. в то время как им нужно было просто в этом конкретном случае сделать sql запрос и замэпить результат на какую-то структурку. Вот как вы репорты делаете с ORM? Допустим у вас есть миллион записей в базе и вы должны в качестве результата получить 3 числа, минимальное значение чего-нибудь, максимальное, медиана. Вы же не будете грузить миллион объектов, так? Вы воспользуетесь каким-то *QL, что бы описать выборку и получить эти числа.

Я не говорю что "не юзайте ORM", хотя и такие фанатики есть. Я лишь говорю что некоторые задачи намного проще решать при помощи dao. В большинстве случаев это работа с read model и выборками. Когда нам нужно просто сделать агрегацию данных какую-то и вывести ее.

Или, например, разработчики зацикливаются на том что "у меня есть mysql и я должен делать все на ней". В то время как никаких проблем сделать агрегацию в какую-нибудь эластику, или хранить связи между объектами в neo4j, в рамках конкретной задачи проще и эффективнее.

[al_gon]

Интересное противостояние и дискуссия. Спасибо Вам Алексей Черемисин и Вам Сергей Протько .
Прочитал с интересом.

Answer 3

[Rou1997]

Работая с JDBC, вы непосредственно работаете с базой данных, ORM же представляет "обертку" для того же JDBC, которая (ORM) реализует паттерны, обеспечивающее большее удобство, помогает ускорить разработку, очевидно что лучше предпочитать второе, но первое проще для простых задач, более гибко, а также помогает освоить второе.