函数到关系的映射比对象到关系更容易吗？

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

想要改进这个问题？更新问题，以便可以通过编辑这篇文章用事实和引文来回答它。

1 年前已关闭。

Answer 1

ORM 的目的是什么？

使用 ORM 的主要目的是在网络模型（面向对象、图形等）和关系模型之间架起桥梁。 这两个模型之间的主要区别出奇地简单。 是父母指向孩子（网络模型）还是孩子指向父母（关系模型）。

考虑到这种简单性，我相信 两种模型之间不存在“阻抗不匹配”。 人们通常遇到的问题纯粹是特定于实现的，如果客户端和服务器之间有更好的数据传输协议，应该可以解决。

SQL 如何解决我们在 ORM 方面遇到的问题？

特别是，第三个宣言试图通过允许嵌套集合，已在各种数据库中实现，包括：

• 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 结果映射到某些先前定义的对象/类。

使用 jOOQ 的 Java 示例 摘自这篇博文 可能是：

// 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 背后的公司工作，所以这个答案有偏见）

Answer 2

扩展关系数据库的难题是扩展事务、数据类型不匹配、自动查询转换以及诸如 N+1 Select 是离开关系系统的基本问题，并且——在我看来——不会通过改变接收编程范式而改变。

Answer 3

这取决于您的需求

1. 如果您想专注于数据结构，请使用像 JPA/Hibernate 这样的 ORM
2. 如果您想阐明处理方法，请查看 FRM 库：QueryDSL 或 Jooq
3. 如果您需要调整 SQL 请求对于特定的数据库，使用 JDBC 和本机 SQL 请求

各种“关系映射”技术的优势在于可移植性：确保您的应用程序能够在大多数 ACID 数据库上运行。
否则，当您手动编写 SQL 请求时，您将面临各种 SQL 方言之间的差异。

当然，您可以限制自己遵守 SQL92 标准（然后进行一些函数式编程），或者您可以使用 ORM 框架重用函数式编程的一些概念

ORM 的优势是建立在会话对象之上的，会话对象可以充当瓶颈：

1. 它管理生命周期只要底层数据库事务正在运行，对象就会被保留。
2. 它维护 java 对象和数据库行之间的一对一映射（并使用内部缓存来避免重复的对象）。
3. 它自动检测关联更新和要删除的孤立对象
4. 它使用乐观或悲观锁处理并发问题。

然而，它的优点也是它的缺点：

1. 会话必须能够比较对象，因此您需要实现 equals/hashCode 方法。
   但对象相等性必须植根于“业务键”而不是数据库 ID（新的瞬态对象没有数据库 ID！）。
   然而，一些具体化的概念没有业务平等（例如操作）。
   常见的解决方法依赖于 GUID，这往往会让数据库管理员感到不安。

2. 会话必须监视关系更改，但其映射规则会推动使用不适合业务算法的集合。
   有时你想使用 HashMap，但 ORM 需要密钥是另一个“丰富域对象”而不是另一个轻量级对象......
   然后，您必须在充当关键的丰富域对象上实现对象相等......
   但你不能，因为这个对象在商业世界中没有对应的对象。
   因此，您退回到必须迭代的简单列表（并由此导致性能问题）。

3. ORM API 有时不适合实际使用。
   例如，现实世界的 Web 应用程序尝试通过在获取数据时添加一些“WHERE”子句来强制会话隔离......
   那么“Session.get(id)”就不够了，你需要转向更复杂的 DSL（HSQL、Criteria API）或返回到本机 SQL

4. 数据库对象与专用于其他框架的其他对象发生冲突（例如 OXM 框架 = 对象/XML 映射）。
   例如，如果您的 REST 服务使用 jackson 库来序列化业务对象。
   但这个 Jackson 与 Hibernate One 完全对应。
   然后要么合并两者，API 和数据库之间就会出现强耦合
   或者您必须实现转换，并且从 ORM 保存的所有代码都会丢失...

另一方面，FRM 是“对象关系映射”(ORM) 和本机 SQL 查询（使用 JDBC）之间的权衡

。解释 FRM 和 ORM 之间差异的最佳方法是采用 DDD 方法。

• 对象关系映射允许使用“富域对象”，这些 Java 类的状态在数据库事务期间是可变的
• 功能关系映射依赖于不可变的“贫域对象”（如此之多，以至于每次都必须克隆一个新对象）你想改变它的内容）

它释放了对 ORM 会话的约束，并且大部分时间依赖于 DSL 而不是 SQL（所以可移植性并不重要）
但另一方面，你必须查看交易细节、并发问题

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

Answer 4

我猜想函数到关系的映射应该比面向对象到 RDBMS 更容易创建和使用。 只要你只查询数据库，就是这样。 我真的不明白（还）如何以一种很好的方式进行数据库更新而不产生副作用。

我看到的主要问题是性能。 如今的 RDMS 并非设计用于功能查询，并且在很多情况下可能表现不佳。

Answer 5

我本身没有进行函数关系映射，但我使用了函数编程技术来加速对 RDBMS 的访问。

从数据集开始，对其进行一些复杂的计算并存储结果是很常见的，例如，结果是带有附加值的原始数据的子集。 命令式方法要求您使用额外的 NULL 列存储初始数据集，进行计算，然后使用计算值更新记录。

看起来很合理。 但问题是它可能会变得非常慢。 如果您的计算除了更新查询本身之外还需要另一个 SQL 语句，或者甚至需要在应用程序代码中完成，那么您实际上必须在计算后（重新）搜索要更改的记录，以将结果存储在正确的行中。

您只需为结果创建一个新表即可解决此问题。 这样，您就可以始终插入而不是更新。 您最终会拥有另一个表，复制键，但您不再需要在存储 NULL 的列上浪费空间 – 您只存储您拥有的内容。 然后，您将结果加入到最终选择中。

我以这种方式（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。

我想这也将使并行性变得更加容易。

一个额外的好处是，不必指定以这种方式创建的表的列类型，因为它们是从从中选择的列中推断出来的。

Answer 6

我认为，正如 Sam 提到的，如果应该更新数据库，则必须面对与 OO 世界相同的并发问题。 由于 RDBMS 的数据、事务等状态，程序的功能性质可能比对象性质更成问题。

但对于阅读而言，函数式语言对于某些问题域可能会更自然（因为它似乎与 DB 无关）。

函数式 RDBMS 映射与 OO-RDBMS 映射应该没有太大差异。 但我认为这在很大程度上取决于您想要使用哪种数据类型，如果您想使用全新的数据库模式开发程序或针对旧数据库模式执行某些操作等。

延迟获取等例如，关联可能可以通过一些与惰性求值相关的概念很好地实现。 （尽管它们也可以用 OO 很好地完成）

编辑：通过一些谷歌搜索，我发现 HaskellDB（Haskell 的 SQL 库）- 这值得尝试吗？

Answer 7

数据库和函数式编程可以融合。

例如：

Clojure是一种基于关系数据库理论的函数式编程语言。

               Clojure -> DBMS, Super Foxpro
                   STM -> Transaction，MVCC
Persistent Collections -> db, table, col
              hash-map -> indexed data
                 Watch -> trigger, log
                  Spec -> constraint
              Core API -> SQL, Built-in function
              function -> Stored Procedure
             Meta Data -> System Table

注意：在最新的spec2中，spec更像是RMDB。
请参阅：spec-alpha2 wiki：架构和选择

我主张：在hash-map之上构建关系数据模型，实现NoSQL和RMDB优势的结合。 这实际上是 posgtresql 的反向实现。

鸭子打字：如果它看起来像鸭子并且嘎嘎叫起来像鸭子，那么它一定是鸭子。

如果 clojure 的数据模型像 RMDB，clojure 的设施像 RMDB，clojure 的数据操作像 RMDB，那么 clojure 一定是 RMDB。

Clojure 是一种基于关系数据库理论的函数式编程语言

一切都是 RMDB

基于hash-map（NoSQL）实现关系数据模型和编程

Answer 8

函数式和面向对象是两个正交的概念。 将平面表映射到对象树的问题与功能性与命令性正交。

然而，函数式与命令式确实解决了一个特定的不匹配，即命令式更新和 MVCC 之间的不匹配。 在命令式编程中，在更新表时锁定正在使用的表是最直观的方法，任何非顺序的操作都是极其违反直觉的。

在FP中，MVCC比锁自然得多。 自然的写入方式是计算结果集，计算与读取数据的差异，写入（即选择更新的数据集作为新数据集，使用持久数据结构共享它们共有的数据），然后进行回滚和恢复。 如果存在写入冲突，请重试。 这与 MVCC 的作用完全一致。