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

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

我想不出使用ORM进行数据库“建模”的原因。 工作。 我能得出的最接近的结果是性能,但是要达到这个规模,这似乎还没有定论。 这样的运行方式是否有不利之处?</ p>
</ div>

展开原文

原文

I've recently inherited a project where the database was modeled interestingly (i.e. lack of some index and foreign key definitions). The project uses GORM and from what I can tell, those Models have tags which define everything correctly.

I can't think of a reason why using the ORM for database "modeling" wouldn't work. The closest I can come is performance, but at the scale this would need to run, the point seems moot. Are there any downsides to this running things this way?

1个回答



在公司做同一件事的唯一缺点是:</ p>


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

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

展开原文

原文

The only downsides I'm aware of from doing the same thing at my company are:

  1. Interoperability - you need to use golang to get everything up and running, so if you have projects that would like to use another language on a new database it gets a bit weird.
  2. Complex SQL stuff - occasionally you'll want to use a complex feature that might be awkward to write tags for (ex: compound indexes require tags on all the fields to use the same index name, but that's weird to mentally parse and you don't get to decide the order)
  3. Migration - if you use the built in AutoMigrate you can get tables, columns, and indices created, but you can't add in default data or write a data transition, nor will it drop columns, nor does it keep a history of changes. If all the developers use the same dev database this isn't too much of an issue, but if you start having separate dbs you'll probably start keeping migration sql files around too, which you'll have to manage separately from Gorm.

I don't regret using it initially as it was much easier to declare the model and the sql in one place to start, but as we grew and started to use more advanced sql features and more databases, we had to switch to doing actually schema definitions and migrations.

Csdn user default icon
上传中...
上传图片
插入图片
抄袭、复制答案,以达到刷声望分或其他目的的行为,在CSDN问答是严格禁止的,一经发现立刻封号。是时候展现真正的技术了!
立即提问
相关内容推荐