NestJS后端是否必须使用entities？熟悉原生SQL如何选择数据库操作方案

一、TypeORM Entities的核心作用 #

Entities本质是TypeORM实现ORM能力的核心载体，核心作用包括以下几点：

• 类型化的表结构映射：把数据库表结构直接转换为带TypeScript类型约束的类，字段名、类型、索引、关联关系都可以通过装饰器在类中声明，开发时不需要来回对照表结构文档，TS的类型检查可以直接规避字段名拼写错误、类型不匹配这类低级问题。
• 减少重复CRUD代码：基于Entity生成的Repository实例内置了大量通用的增删改查API，比如save()、findOneBy()、delete()等，不需要手写大量重复的基础SQL，开发效率更高。
• 自动处理关联关系：表与表之间的一对多、多对多等关联可以直接通过@OneToMany、@ManyToMany等装饰器声明，查询时指定关联加载即可自动带出关联数据，不需要手动编写复杂的JOIN语句。
• 支持自动生成迁移脚本：可以直接根据Entity的变更自动生成数据库迁移脚本，不需要手动编写ALTER TABLE这类SQL来更新表结构，适合迭代频繁的项目。

二、熟悉原生SQL的前提下是否必须使用Entities #

完全不是必须的。
NestJS本身对数据库操作的技术选型没有任何强制限制，你完全可以沿用之前Express的开发习惯：

• 可以直接使用pg等数据库原生驱动，全量手写原生SQL完成所有数据库操作
• 也可以搭配Knex.js这类轻量SQL查询构建器，简化SQL拼接、参数处理的逻辑
• 就算你选择使用TypeORM，也可以跳过Entity层，直接调用entityManager.query()方法执行任意原生SQL，完全适配你的开发习惯

只有当你需要用到TypeORM的全量ORM能力时，才需要用到Entities，否则完全可以删除entities目录，按自己熟悉的模式开发即可，NestJS不会做任何强制约束。

三、NestJS操作数据库的主流最佳实践 #

• 按需选择操作方案：中小项目、业务逻辑简单的场景，用TypeORM+Entities的开发效率更高；复杂查询多、对SQL性能要求高的场景，直接用原生SQL即可，不需要硬套ORM的API反而增加开发成本。
• 数据库逻辑分层封装：所有数据库操作逻辑都统一封装在Service层的专属Provider中，禁止在Controller中直接编写SQL，方便后续统一调试、加缓存、做逻辑复用。
• 强制使用参数化查询：不管是手写原生SQL还是用ORM，都必须使用参数化查询，禁止手动拼接SQL字符串，彻底避免SQL注入风险，比如使用pg驱动时按client.query('SELECT * FROM users WHERE id = $1', [userId])的格式编写。
• 统一管理数据库迁移：不管是ORM自动生成的迁移脚本，还是手写的SQL迁移，都要纳入项目版本管理，禁止直接在生产环境手动修改表结构。
• 统一配置连接池：在NestJS的数据库模块配置中统一设置连接池参数，避免每次数据库操作都新建连接，提升服务性能。

内容的提问来源于stack exchange，提问作者Hung Vu