使用 ORM 模型而不是正确的数据库建模

Question

我最近继承了一个项目，其中数据库的建模很有趣（即缺少一些索引和外键定义）。该项目使用 GORM，据我所知，这些模型具有正确定义所有内容的标签。我想不出为什么使用 ORM 进行数据库“建模”不起作用的原因。我能得出的最接近的是性能，但就其运行所需的规模而言，这一点似乎没有实际意义。以这种方式运行有什么缺点吗？

Answer 1

我知道在我的公司做同样的事情的唯一缺点是：

1. 互操作性 - 您需要使用 golang 来启动和运行所有内容，因此，如果您的项目想要在新数据库上使用另一种语言，那就有点奇怪了。

2. 复杂的 SQL 东西 - 有时你会想要使用一个复杂的功能，可能很难编写标签（例如：复合索引要求所有字段上的标签使用相同的索引名称，但这在心理上解析很奇怪，而你不这样做）不能决定顺序）

3. 迁移 - 如果您使用内置功能，AutoMigrate您可以创建表、列和索引，但不能添加默认数据或编写数据转换，也不会删除列，也不会保留更改历史记录。如果所有开发人员都使用相同的开发数据库，这并不是什么大问题，但如果您开始拥有单独的数据库，您可能也会开始保留迁移 sql 文件，您必须与 Gorm 分开管理。

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