Какова цель ORM?
Основной целью использования ORM является мост между сетевой моделью (ориентация объекта, графики и т. Д.) И реляционной моделью. И главное отличие двух моделей на удивление простое. Вопрос в том, указывают ли родители на детей (сетевая модель) или дети указывают на родителей (реляционная модель).
Учитывая эту простоту, я считаю, нет такой вещи, как "несоответствие импеданса" между двумя моделями. Проблемы, с которыми обычно сталкиваются люди, связаны исключительно с реализацией и должны решаться, если бы существовали лучшие протоколы передачи данных между клиентами и серверами.
Как SQL может решить проблемы, возникающие у нас с ORM?
В частности, третий манифест пытается устранить недостатки языка SQL и реляционной алгебры, допуская вложенные коллекции, которые были реализованы в различных базах данных, включая:
- Oracle (возможно, самая сложная реализация)
- PostgreSQL (в некоторой степени)
- Informix
- SQL Server, MySQL и т. Д. (Через «эмуляцию» через XML или JSON)
По моему мнению, если бы во всех базах данных был реализован стандартный оператор SQL MULTISET() (например, в Oracle), люди больше не использовали бы ORM для отображения (возможно, все еще для сохранения графов объектов), потому что они могли материализовать вложенные коллекции непосредственно из базы данных, например этот запрос:
SELECT actor_id, first_name, last_name,
MULTISET (
SELECT film_id, title
FROM film AS f
JOIN film_actor AS fa USING (film_id)
WHERE fa.actor_id = a.actor_id
) AS films
FROM actor AS a
Даст все актеры и их фильмы как вложенную коллекцию, а не денормализованный результат объединения (где актеры повторяются для каждого фильма).
Функциональная парадигма на стороне клиента
Вопрос о том, подходит ли функциональный язык программирования на стороне клиента для взаимодействия с базой данных, действительно ортогональн. ORM помогают с сохранением графов объектов, поэтому, если ваша клиентская модель представляет собой граф, и вы хотите, чтобы он был графом, вам потребуется ORM, независимо от того, манипулируете ли вы этим графом с помощью функционального языка программирования.
Однако, поскольку в функциональных языках программирования ориентация объекта менее идиоматична, вы с меньшей вероятностью включите каждый элемент данных в объект. Для тех, кто пишет SQL, проецирование произвольных кортежей очень естественно. SQL охватывает структурную типизацию. Каждый запрос SQL определяет свой собственный тип строки без необходимости предварительно назначать ему имя. Это очень хорошо согласуется с функциональными программистами, особенно когда сложный вывод типов, в случае которого вы никогда не будете думать о сопоставлении своего результата SQL с каким-либо ранее определенным объектом / классом.
Пример в Java, использующий jOOQ из этого сообщения в блоге может быть:
// Higher order, SQL query producing function:
public static ResultQuery<Record2<String, String>> actors(Function<Actor, Condition> p) {
return ctx.select(ACTOR.FIRST_NAME, ACTOR.LAST_NAME)
.from(ACTOR)
.where(p.apply(ACTOR)));
}
Этот подход приводит к гораздо лучшей композиционности операторов SQL, чем если бы язык SQL был абстрагирован каким-либо ORM или если использовалась естественная "строковая" природа SQL. Вышеупомянутая функция теперь может быть использована, например, как это:
// Get only actors whose first name starts with "A"
for (Record rec : actors(a -> a.FIRST_NAME.like("A%")))
System.out.println(rec);
FRM абстракция над SQL
Некоторые FRM пытаются абстрагироваться от языка SQL, обычно по следующим причинам:
- Они утверждают, что SQL недостаточно композируем (jOOQ это опровергает, просто очень трудно понять, что правильно).
- Они утверждают, что пользователи API более привыкли к "нативным" API коллекции, например,
JOIN переводится в flatMap() и WHERE переводится в filter() и т. Д.
Чтобы ответить на ваш вопрос
FRM не "проще", чем ORM, он решает другую проблему. На самом деле FRM вообще не решает никаких проблем, потому что SQL, сам по себе являющийся декларативным языком программирования (который ничем не отличается от функционального программирования), очень хорошо подходит для других функциональных языков программирования клиента. Таким образом, FRM просто устраняет разрыв между SQL, внешним DSL и языком вашего клиента.
(я работаю в компании за jOOQ , поэтому этот ответ предвзят)