Функционально к Реляционному отображению, легче, чем Объект к Реляционному?

Какова цель 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 , поэтому этот ответ предвзятый)

Я предположил бы функциональный к реляционному отображению, должно быть легче создать и использовать, чем OO для RDBMS. Пока Вы только запрашиваете базу данных, которая является. Я (еще) действительно не вижу, как Вы могли сделать обновления базы данных без побочных эффектов хорошим способом.

основной проблемой, которую я вижу, является производительность. Сегодняшние RDMS не разработаны, чтобы использоваться с функциональными запросами и будут, вероятно, вести себя плохо в довольно многих случаях.

Я не сделал функционально-реляционного отображения, по сути , но я использовал методы функционального программирования для ускорения доступа к RDBMS.

довольно распространено запуститься с набора данных, сделать некоторое сложное вычисление на нем и сохранить результаты, где результатами является подмножество оригинала с дополнительными значениями, например. Обязательный подход диктует, что Вы снабжаете свой начальный набор данных дополнительными столбцами NULL, делаете Ваше вычисление, затем обновляете записи с вычисленными значениями.

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

можно обойти это путем простого составления новой таблицы для результатов. Таким образом, можно просто всегда вставлять вместо обновления. Вы заканчиваете тем, что имели другую таблицу, делая дубликаты ключа, но Вы больше не должны тратить впустую пространство на столбцы, хранящие ПУСТОЙ УКАЗАТЕЛЬ – Вы только храните то, что Вы имеете. Вы тогда присоединяетесь к своим результатам в Вашем заключительном выборе.

я (ab) использовал RDBMS этот путь и закончил тем, что писал SQL-операторы, которые походили главным образом на это...

create table temp_foo_1 as select ...;
create table temp_foo_2 as select ...;
...
create table foo_results as
  select * from temp_foo_n inner join temp_foo_1 ... inner join temp_foo_2 ...;

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

я предполагаю, что это также допускало бы намного легче параллелизм.

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

Я думал бы, что, как Sam упомянул, если DB должен быть обновлен, как те же проблемы параллелизма нужно столкнуться с миром OO. Функциональная природа программы могла, возможно, быть даже немного более проблематичной, чем объектная природа из-за состояния данных, транзакции и т.д. RDBMS.

, Но для чтения, функциональный язык мог быть более естественным с некоторыми проблемными областями (поскольку это, кажется, независимо от DB)

functional<-> отображение RDBMS не должно иметь никаких больших различий для OO<-> отображения RDMBS. Но я думаю, что это во многом зависит от того, какие типы данных Вы хотите использовать, если Вы хотите разработать программу с совершенно новой схемой DB или сделать что-то против схемы DB прежней версии и т.д.

ленивые выборки и т.д. для ассоциаций, например, могли, вероятно, быть реализованы вполне приятно с некоторыми отложенными вычислениями связанные понятия. (Даже при том, что они могут быть сделаны вполне приятно с OO также)

Редактирование: С некоторым гуглением я нашел HaskellDB (библиотека SQL для Haskell) - который могло стоить попробовать?