事务脚本也是 NoSQL 数据库的反模式吗？

Posted 2023-02-24

【中文标题】事务脚本也是 NoSQL 数据库的反模式吗？

【英文标题】：Is Transaction Script an antipattern with NoSQL databases also?

【发布时间】：2012-12-04 03:59:00

【问题描述】：

http://martinfowler.com/articles/dblogic.html

使用上面文章的术语，在处理 SQL 数据库时，Transaction Script 编码模式显然是一种反模式。

NoSQL 数据库（如 MongoDB）是否也是如此？假设 nosql 查询将使用的列都已适当索引。

我问这个问题的原因是：MongoDB 中的查询执行返回一个游标，可以对其进行迭代。我不知道的是，是否存在与之相关的性能损失。

【问题讨论】：

你为什么不赞成这个问题 - 为什么？？？

NoSQL 数据库有很多种，它们的理念完全不同。也许这对他们中的一些人来说是正确的，也许对其他人来说是错误的。

【参考方案1】：

文章将“事务脚本”描述为

[a] 过程读取它可能需要的所有数据，然后在内存中进行选择和操作以确定需要哪些[数据库条目]。

每个 NoSQL 数据库都是不同的，因此您不能为“NoSQL”一概而论。但在几乎每个数据库系统中，尽可能多地对数据库进行操作是个好主意。

只要你使用数据库的查询语法，至少理论上可以使用索引来加速某些操作，但是一旦返回结果集，索引信息就丢失了，这使得这些操作更贵。 当您从数据库中获得大量结果集，然后在应用层对其进行过滤时，您必须通过网络传递所有这些数据。根据您的网络基础设施的运行情况，这可能会成为性能瓶颈（假设您的数据库在不同的物理服务器上——它通常应该在生产环境中）。传输庞大的数据集也会对数据库的任何缓冲系统或数据库驱动程序造成困扰。

当您专门询问 MongoDB 时：MongoDB 数据库的设计并不像 SQL 数据库那样“智能”。该设计假设 SQL 数据库自己解决的许多问题都在应用层解决（约束、级联删除、连接、事务......）。查询语法也没有 SQL 发展 40 年积累的所有功能强大。这意味着您通常不会在应用程序层上进行过滤。但是当查询语法可以解决问题时，您通常应该尝试这样做。