使用ORM模型代替正确的数据库建模

Question

我最近继承了一个项目，其中对数据库进行了有趣的建模（即缺少一些索引和外键定义）。 该项目使用GORM，据我所知，这些模型具有正确定义所有内容的标签。

我想不出为什么将ORM用于数据库“建模”的原因。 我能得出的最接近的结果是性能，但是要达到这个规模，这似乎还没有定论。 这样的运行方式是否有不利之处？

Answer 1

在公司做同样的事情，我唯一意识到的缺点是：

1. 互操作性-您需要使用golang来启动和运行所有内容，因此，如果您有想要在新数据库上使用另一种语言的项目，那会有些奇怪。
2. 复杂的SQL内容-有时您会想要使用一个复杂的功能来为其编写标签（例如：复合索引要求所有字段上的标签都使用相同的索引名称，但是在精神上解析很奇怪，而您却不会无法决定顺序）
3. 迁移-如果使用内置的AutoMigrate ，则可以创建表，列和索引，但是您不能添加默认数据或编写数据转换，也不能删除列，也不会保留更改历史记录。 如果所有开发人员都使用同一个dev数据库，那么这并不是什么大问题，但是如果您开始拥有单独的数据库，那么您可能也将开始保留迁移sql文件，而这些文件必须与Gorm分开进行管理。

我并不后悔使用它，因为在一个地方声明模型和sql更加容易，但是随着我们逐渐成长并开始使用更高级的sql功能和更多的数据库，我们不得不改用实际的模式定义和迁移。