原始 SQL 与 ORM 如果我已经知道 SQL

Posted 2023-04-12

【中文标题】原始 SQL 与 ORM 如果我已经知道 SQL

【英文标题】：raw SQL vs ORM If I already know SQL

【发布时间】：2019-11-20 05:33:25

【问题描述】：

我目前正在使用 PostgreSQL 和 nodejs。 到目前为止，我已经使用带有pg 驱动程序的原始SQL 进行了开发。 我希望我的服务在不久的将来会有相当多的记录。(10k+)

我已经对 SQL 与 ORM 进行了一些研究，因为这不是一个新问题。 据我了解，

SQL 性能更好， ORM 增强了代码的可读性，减少了代码长度，比 SQL 更容易学习。

这项研究http://www.diva-portal.org/smash/get/diva2:1014983/FULLTEXT02 表明，当行数增加时，原始 SQL 和 ORM 之间的性能差异非常大。因为研究是用Laravel ORM进行的，所以我知道nodejs ORM sequelize的结果可能不同。

我的代码很长，因为我的函数中有 SQL 字符串。如果我已经知道如何编写 SQL，是否应该切换到 ORM？

添加： 如果我要实现 ORM，因为我有一些复杂的查询连接和聚合多个表，如果我将 ORM 用于简单的 SELECT 和 INSERT 并将原始 SQL 用于复杂的查询，这是不是一个糟糕的选择？

【问题讨论】：

What ORMs have taught me: just learn SQL

【参考方案1】：

我最近遇到了类似的事情，将与您分享我的经验。

我主要有数据库背景（SQL / 存储过程），有一点 UI 经验。去年，我使用 Postgres 和 Django 从头开始​​编写了我的第一个 Web 应用程序，然后自己开始编写整个 DB 接口，因为我只知道这些。我以前从未使用过内置 ORM，甚至不知道它是什么或它的好处。

一开始是令人兴奋和有趣的，因为您可以控制所有数据库操作，并且还可以更好地了解所有代码的工作原理。不过，过了一会儿，我意识到了一些缺点：

大多数 Django / Python 模块都设计为使用 Django 的 ORM。我很难让他们中的很多人使用我的自定义界面。一个例子是他们希望有一个“id”列作为所有相关表的 PK。另一个问题是不支持多列 PK。

如果创建新对象，需要创建多组存储过程/函数来管理它们；过了一会儿就变得乏味了

如果您的架构发生更改并且您想要升级已经有数据的安装，您必须创建自己的升级脚本

构建自己的界面的主要优点之一是您可以完全控制物理数据库模型（即您可以选择索引/键、自定义命名约定等）。

如果您没有提到对性能的关注，那么我会建议只使用提供的 ORM，因为它可以更轻松地与其他模块集成，并且更容易处理对新对象的支持。

这真的取决于这些因素对你有多重要：

开发时间 维护 性能 可定制性（即自定义 SQL） 能够与其他模块交互

如果性能和可定制性是一个大问题，并且您不打算合并第 3 方模块，那么我会考虑自己编写界面。否则，我会说只使用 ORM 会更容易。