Prisma和TypeORM的区别

改表结构,两种工具都绕不开一件事:先有一份「结构描述」,再让工具生成/执行 SQL,最后代码类型跟上。差别主要在改哪里、谁生成 SQL、备注怎么管


共同的地方

共同点说明
都要描述表结构Prisma:schema.prisma;TypeORM:带@Entity/@Column的实体类
都能做迁移(Migration)把变更记成版本,可重复部署到 dev/staging/prod
最终都是 MySQL DDLALTER TABLE ... ADD COLUMN ...这类语句
改完都要更新「访问层」Prisma:prisma generate;TypeORM:重新编译,类型来自实体
两种工作流都支持库先行(先在 MySQL 改表再同步到代码)或代码先行(先改描述再推到库)

不同:改表时各自怎么做

方式 A:代码先行(团队开发常用)

Prisma

  1. prisma/schema.prisma,例如:
model users { id BigInt @id @default(autoincrement()) username String remark String? @default("") @db.VarChar(200) // 新列 }
  1. 生成并应用迁移:
npx prisma migrate dev--nameadd_user_remark
  1. 重新生成 Client:
npx prisma generate

Prisma 会生成prisma/migrations/.../migration.sql,里面是ALTER TABLE

TypeORM

  1. 改实体类:
@Entity('users')exportclassUser{@PrimaryGeneratedColumn({type:'bigint'})id:string@Column({length:200,default:'',comment:'备注'})remark:string}
  1. 生成并执行迁移:
npmrun typeorm migration:generate ---nAddUserRemarknpmrun typeorm migration:run

TypeORM 对比「当前库」和「实体定义」,生成ALTER TABLE迁移文件。


方式 B:数据库先行(你项目现在更接近这种)

你们 admin 用过prisma db pull,schema 是从 MySQL反推的,且目前没有prisma/migrations/目录。

流程可以是:

  1. 在 MySQL 里直接改(或 DBA 工具):
ALTERTABLEusersADDCOLUMNremarkVARCHAR(200)NOTNULLDEFAULT''COMMENT'备注';
  1. 再同步到代码:
# Prismanpx prisma db pull npx prisma generate
# TypeORM:没有 pull 一键等价物,一般要手改 Entity,# 或用工具反向生成实体,再补迁移记录

共同风险:库改了、代码没跟上 → 运行时报错或类型不对,所以pull / 改实体之后一定要 generate / 编译


分项对比:类型、默认值、备注

能力PrismaTypeORM
列类型StringIntBigIntDateTime,细化为@db.VarChar(200)@Column({ type: 'varchar', length: 200 })
可空String?nullable: true
默认值@default("")@default(now())@default(0)default: ''default: () => 'NOW()'
列备注 COMMENT支持有限;你 schema 里已有提示:DB 有 comment 时migrate 要额外配置@Column({ comment: '备注' })较直接
表备注类似,偏麻烦@Entity({ comment: '...' })
迁移文件prisma/migrations/*/migration.sqlsrc/migrations/*.ts里写up/down
开发快速同步(慎用生产)prisma db push(不生成迁移历史)synchronize: true生产别用

新增一列:并排例子

需求:users表加remarkVARCHAR(200),默认'',备注「用户备注」。

Prisma(schema 先行 + migrate)

remark String @default("") @db.VarChar(200)

migrate dev→ 生成ALTER TABLE users ADD COLUMN remark ...

TypeORM(entity 先行 + migration)

@Column({type:'varchar',length:200,default:'',comment:'用户备注'})remark:string

migration:generate→ 生成类似 SQL 的迁移

共同结果:MySQL 多一列;应用代码里多一个字段。


和你当前项目的注意点

  1. BIGINT 主键:两边都要注意 JS 里用string/bigint,不是number(你们 admin 已处理)。
  2. 你若继续db pull:改表在MySQL 做pullgenerate,不必强行上migrate,但团队要有「谁改库、谁 pull」的约定。
  3. 若要正规发版:建议逐步改用Prisma Migratemigrate dev/migrate deploy),和 TypeORM 的migration:run一样,都是可追踪的变更历史
  4. IM 还在 mysql2:改表后 Prisma schema 和 IM 手写 SQL 要一起改;只改一边会线上炸。

怎么选工作流(实用)

场景建议
个人/小团队、库已存在MySQL 改表 → Prismadb pull(你现在)
多人协作、要版本化schema.prismamigrate dev
Nest + 实体风格TypeORM 改 Entity →migration:generate
列备注很重要TypeORM 写 comment 更顺手;Prisma 往往 SQL 里写 COMMENT 或接受 pull 带回

一句话

  • 共同:都要维护「结构描述」→ 生成/执行ALTER TABLE→ 更新 Client/实体。
  • 不同:Prisma 改.prisma文件+migrate/pull;TypeORM 改实体类装饰器+migration:generate
  • 备注:TypeORM 在代码里写comment更直接;Prisma 对 MySQL COMMENT 支持较弱,你项目里已有相关提示。

若你打算以后固定用「先改 schema 再 migrate」还是「先改 MySQL 再 pull」,可以说一下,我可以按你仓库现状给一套固定流程(仍不改代码,只给步骤)。