我最近继承了一个有趣的数据库建模项目(即缺少一些索引和外键定义)。该项目使用 GORM，据我所知，这些模型具有正确定义所有内容的标签。
我想不出为什么使用 ORM 进行数据库“建模”不起作用的原因。我能想到的最接近的是性能，但在这需要运行的规模上，这一点似乎没有实际意义。以这种方式运行有什么缺点吗？
最佳答案
我知道在我的公司做同样的事情的唯一缺点是:
- 互操作性 - 您需要使用 golang 来启动和运行所有内容，因此如果您的项目想要在新数据库上使用另一种语言，那就有点奇怪了。
- 复杂的 SQL 东西 - 偶尔你会想要使用一个复杂的功能，可能很难为其编写标签(例如:复合索引要求所有字段上的标签使用相同的索引名称，但这在精神上解析和你不能决定顺序)
- 迁移 - 如果您使用内置的
AutoMigrate，您可以创建表、列和索引，但您不能添加默认数据或编写数据转换，也不会删除列，也不保留更改历史记录。如果所有开发人员都使用同一个开发数据库，这不是什么大问题，但如果你开始拥有单独的数据库，你可能也会开始保留迁移 sql 文件，你必须与 Gorm 分开管理。
我不后悔最初使用它，因为在一个地方声明模型和 sql 更容易开始，但是随着我们的成长并开始使用更高级的 sql 功能和更多数据库，我们不得不切换到实际执行模式定义和迁移。
关于database - 使用 ORM 模型而不是正确的数据库建模，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/56675994/