Функционально для реляционного сопоставления проще, чем Object to Relational?

Question

Объектно-реляционное сопоставление хорошо обсуждается, в том числе и здесь. У меня есть опыт с несколькими подходами, ловушками и компромиссами. Истинное разрешение похоже, что оно требует изменений в OO или самих реляционных моделях.

Если вы используете функциональный язык, возникает ли та же проблема? Мне кажется, что эти две парадигмы должны сочетаться лучше, чем OO и RDBMS. Идея думать в наборах в РСУБД, похоже, сводится к автоматическому параллелизму, который, по-видимому, обещает функциональные подходы.

Есть ли у кого-нибудь интересные мнения или идеи? Каково состояние игры в отрасли?

Answer 1

Трудными проблемами расширения реляционной базы данных являются расширенные транзакции, несоответствия типа данных, автоматический перевод запросов и такие вещи, как N+1 Select, которые являются фундаментальными проблемами выхода из реляционной системы и, по моему мнению, не изменяются путем изменения принимающей парадигме программирования.

Answer 2

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

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

Answer 3

Я подумал бы, что, как сказал Сэм, если БД необходимо обновить, то такие же проблемы параллелизма должны быть рассмотрены как с миром ОО. Функциональный характер программы может быть даже немного более проблематичным, чем природа объекта из-за состояния данных, транзакций и т. Д. СУРБД.

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

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

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

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

Answer 4

Я не выполнял функционально-реляционное сопоставление, как таковое, но я использовал методы функционального программирования для ускорения доступа к РСУБД.

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

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

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

I (AB) используется СУБД таким образом, и в конечном итоге написание заявления 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.

Я предполагаю, что это также облегчит параллелизм.

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

Answer 5

Это зависит от ваших потребностей

1. Если вы хотите, чтобы сосредоточить внимание на структуры данных, использовать ORM, как JPA/Hibernate
2. Если вы хотите, чтобы пролить свет на лечении, посмотри на FRM библиотеки: QueryDSL или Jooq
3. Если вам необходимо настроить ваши запросы SQL к конкретным базам данных, использовать JDBC и нативный SQL запросов

Strengh различных «Relational Mapping» технологий является портативность: вы убедитесь, что ваше приложение будет работать на большинстве баз данных ACID. В противном случае вы сможете справиться с различиями между различными диалектами SQL при написании запросов SQL вручную.

Конечно, вы можете сдерживать себя стандарт SQL92 (а затем сделать некоторые функциональное программирование) или вы можете использовать некоторые концепции Функционального программирования с использованием ORM каркасов

ОРМ strenghs построен через объект сеанса, который может действовать в качестве узкого места:

1. Управление жизненным циклом объектов при условии выполнения основной транзакции базы данных.
2. поддерживает сопоставление «один к одному» между вашими Java-объектами и строками базы данных (и использует внутренний кеш, чтобы избежать дублирования объектов).
3. автоматически определяет обновления ассоциаций и объекты-сироты для удаления
4. он обрабатывает параллельные проблемы с оптимистичным или пессимистичным замком.

Тем не менее, ее сильные и слабые стороны его:

1. Сеанс должен иметь возможность сравнивать объекты, так что вы должны инвентарем равно методы/Hashcode. Но равенство объектов должно основываться на «Бизнес-ключах», а не на идентификаторе базы данных (новые транзиторные объекты не имеют идентификатора базы данных!). Однако некоторые концептуальные концепции не имеют делового равенства (например, операция). Общепринятое обходное решение основывается на GUID, которые склонны нарушать администраторы баз данных.

2. Сессия должна изменить отношения шпиона, но ее правила сопоставления используют использование сборников, непригодных для бизнес-алгоритмов. Когда-нибудь вы хотели бы использовать HashMap, но ORM потребует, чтобы ключ был другим «Rich Object Object» вместо другого легкого ... Тогда вам нужно реализовать равенство объектов на объекте rich domain, действующем как ключ. .. Но вы не можете, потому что этот объект не имеет аналогов в мире бизнеса. Итак, вы возвращаетесь к простому списку, который вам нужно повторить (и возникают проблемы с производительностью).

3. ORM API иногда непригодны для использования в реальном времени. Например, веб-приложения реального мира пытаются обеспечить изоляцию сеанса, добавив некоторые предложения «WHERE» при получении данных ... Тогда «Session.get (id)» недостаточно, и вам нужно перейти к более сложным DSL (HSQL, Criteria API) или вернуться к собственному SQL

4. Объекты базы данных конфликтуют с другими объектами, предназначенными для других фреймворков (например, OXM frameworks = Object/XML Mapping). Например, если ваши службы REST используют библиотеку jackson для сериализации бизнес-объекта. Но этот Джексон точно сопоставляется с Hibernate One. Тогда либо вы сливаете как и сильная связь между API и базой данных появляется Или вы должны осуществить перевод и весь код, вы спасены от ОРМ теряется там ...

С другой стороны , FRM является компромиссом между «Реляционным сопоставлением объектов» (ORM) и собственными SQL-запросами (с JDBC)

Лучший способ объяснить различия между FRM и ORM заключается в принятии подхода DDD.

• Object Relational Mapping дает возможность использовать «Rich Domain Object», которые являются Java-классы, состояния изменчивы во время транзакции базы данных
• Функциональная Relational Mapping опирается на «бедных доменных объектов», которые неизменны (настолько вы должны клонировать новый каждый раз, когда хотите изменить его содержимое)

Он освобождает ограничения, помещенные на сеанс ORM, и большую часть времени полагается на DSL над SQL (поэтому переносимость не имеет значения) Но, с другой стороны, вы должны изучить детали транзакции, concurrenc y выпуски

List<Person> persons = queryFactory.selectFrom(person) 
    .where(
    person.firstName.eq("John"), 
    person.lastName.eq("Doe")) 
    .fetch();