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

Question

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?

Answer 1

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.