在阅读本文之前，请勿使用 Prisma ORM！
想象一下混乱的情况，您在 NeonDB 中创建一个具有 0.5GB 存储空间的免费数据库，然后想，“很好，我将使用免费层进行测试”。然后，几个小时后，收到了致命的电子邮件：“您的存储空间已被消耗！”。哇，你什么意思？连椅子都没有热起来！答案是什么呢？我使用了辉煌的 Prisma ORM，为了改进，我全天运行了几次迁移，只是对模式进行建模。
让我们了解发生了什么，当然，为什么有时好的旧 SQL 仍然要好一千倍。
首先你需要了解自己的背景。我正在录制 CrazyStack 课程 124（我的 Node 和 React 训练营）。并且可以在没有 ORM 的情况下使用 postgres 或 mongodb。然而，一名学生在 WhatsApp 上要求我将 Prisma 纳入该项目。嘿嘿，我决定做个实验。
Prisma ORM：简单但昂贵
Prisma 是那种看起来很完美的东西。 “我将抽象数据库查询，节省时间，这就是新的炒作。”但是，惊喜！天下没有免费的午餐，而这个兰戈是以烘烤存储的形式出现的。我白天运行了迁移，并且neondb的负载很重。而且这甚至不是一个巨大的项目。
Prisma 不仅创建迁移，还留下一些额外的表和日志作为奖励。如果您像我一样正在测试事物并左右运行迁移，那么这份礼物最终来自希腊语。
Prisma 非常好，但在存储方面，它喜欢泼出去：
轮次迁移：每次我运行迁移时，Prisma 都会创建并存储新的迁移。每个都有自己的元数据、日志和表格小包。
成倍增加的日志：为了确保不会出现问题（或者在出现问题时让您的生活更轻松），Prisma 会记录详细的日志。但这些日志会不断积累，而且由于我不是“无限”银行，它们很快就会成为一个问题。
使用辅助表重载：除了迁移之外，Prisma 还创建额外的表来跟踪各种事物，特别是在关系数据库中，例如 Postgres。
最后，这个看似简化生活的神奇工具最终吃掉了我的免费NeonDB。
SQL“Na Nail”：为什么少即是多
这就是古老的 SQL 方法的用武之地。是的，Prisma 很棒并且可以节省时间，但有时它只会让事情变得复杂。让我们谈谈放弃 ORM 并手动编写查询的优点：
绝对控制：账单上没有什么意外。您确切地知道每行代码在做什么，并且您不会发现日志或隐藏表占用您的空间。
No Dead Weight：使用直接 SQL，你写的就是银行的内容。没有元数据、迁移或日志会降低风险。
更高性能：如果做得好，直接 SQL 会消耗更少的空间和资源。对于像我这样的免费主义者来说，它是像 NeonDB 这样的小型银行的理想选择。
没有隐藏业务：没有从头开始创建的表或堆积的事务日志。控制权是你的，而且只属于你。
这个故事的寓意：
如果您像我一样喜欢测试工具并进行快速实验，请在将 Prisma ORM 放入低空间数据库之前三思而后行。 Prisma 是一个奇迹吗？和。但是，在像 NeonDB 这样的有限银行中，这就像开派对时发现你买的啤酒不足以满足每个人的需求。
有时，“即时”SQL 是最安全的方式，让您可以精确控制进入数据库的内容。教训是：下次，在 0.5GB 存储体上运行一个又一个迁移之前，我会考虑得更好。
以上就是在阅读本文之前，请勿使用 Prisma ORM！的详细内容，更多请关注其它相关文章！