Ну, одна вещь, которую важно делать, когда мы обсуждаем подобное, - это четко различать реляционные объекты (ORM) и уровни абстракции базы данных . ORM является своего рода уровнем абстракции базы данных, но не все уровни абстракции базы данных являются ORM. Одним из хороших инструментов для изучения этого является популярная библиотека Python SQLAlchemy , которая позиционирует себя как «инструментарий SQL и Object Relational Mapper» (мой жирный шрифт) с идеей, что это разные вещи. Как они написали на своей странице основных функций :
ORM не требуется
SQLAlchemy состоит из двух отдельных компонентов, известных как ядро и ORM . Ядро само по себе является полнофункциональным инструментарием абстракции SQL, обеспечивающим плавный уровень абстракции в широком спектре реализаций и поведений DBAPI, а также язык выражений SQL, который позволяет выражать язык SQL через генеративные выражения Python. Система представления схемы, которая может генерировать операторы DDL, а также анализировать существующие схемы, и система типов, которая позволяет любое отображение типов Python на типы базы данных, завершают систему. Object Relational Mapper тогда является необязательным пакетом, который основывается на Ядре.
Главная страница описывает ORM следующим образом:
SQLAlchemy наиболее известен своим объектно-реляционным сопоставителем (ORM), необязательным компонентом, который предоставляет шаблон сопоставления данных, где классы могут быть сопоставлены с базой данных открытым способом, несколькими способами - позволяя объектной модели и схеме базы данных развиваться в Чисто развязанный путь с самого начала.
Ключевой идеей ORM является попытка преодоления известного несоответствия объектно-реляционного импеданса . Это означает определение взаимосвязей между пользовательскими классами с таблицами в схеме базы данных и автоматические операции «сохранения» и «загрузки» для классов вашего приложения.
Напротив, уровни абстракции базы данных, отличные от ORM, как правило, более привязаны к реляционной модели данных и к SQL, а не к объектно-ориентированной. Поэтому вместо того, чтобы показывать «отображения» между таблицами и классами и скрывать схему базы данных от программиста, они стремятся предоставить базу данных программисту, но с лучшими API и абстракциями. Например, построители SQL-запросов позволяют вам генерировать сложные SQL-запросы программно, без манипуляций со строками, например так ( пример из библиотеки jOOQ для Java ):
// Typesafely execute the SQL statement directly with jOOQ
Result<Record3<String, String, String>> result =
create.select(BOOK.TITLE, AUTHOR.FIRST_NAME, AUTHOR.LAST_NAME)
.from(BOOK)
.join(AUTHOR)
.on(BOOK.AUTHOR_ID.equal(AUTHOR.ID))
.where(BOOK.PUBLISHED_IN.equal(1948))
.fetch();
Теперь платформа Play, похоже, не на 100% совпадает с тем, что я только что описал , но их аргумент, похоже, заключается в этом общем пространстве: работать с реляционной моделью напрямую, а не переводить ее в классы и обратно от них.
Библиотека jOOQ заслуживает изучения в качестве контрапункта для ORM. У них также есть некоторые соответствующие записи в блоге, которые стоит прочитать: