ORMs have their place but they are IMHO overused and frequently fail for reasons that have to do with the good old object impedance mismatch; which is a pitfall that lots of junior developers fall into where they over engineer their database schema to make it resemble some platonic ideal of some class hieararchy. When that hierarchy inevitably starts changing, the schema erodes along with it.
Some symptoms that I've seen in multiple projects:
- requests are slow because every request triggers dozens to hundreds of joins.
- overuse of the @Transactional annotation (spring/hibernate) because of developers slapping it on anything that looks like it might be doing anything with a database while neither understanding transactional semantics or aspect oriented programming (which causes some funny behavior)
- Attempts to implement class inheritance via database tables and corresponding hacks and complexity to query because of that.
- Lack of a coherent database design. IMHO, a good use of ORM should start with a good old database design. A 1 to 1 mapping of your domain to tables is typically not it.
- Over and under use of database constraints, indices, etc. because of a lack of knowledge of how databases actually work resulting in unenforced referential integrity constraints, poor performance, and weak transactional semantics.
I've used lots of different styles of databases over the years. I generally break things down into:
- simple key value stores like redis, memcached, etc.
- document databases like couchdb, elasticsearch. These tend to have schemas and fields
- Nosql object databases (mongodb, firestore, etc.
I tend to mix these styles and would happily use postgres as a document store. IMHO if I'm not going to query on it, putting it in separate column adds little or no value. If I am going to query on it; it should have an index.
Years of using document stores have taught me the value of de-normalizing stuff like user names and other things that rarely change but are a part of pretty much everything. I've ripped out hibernate in favor of JDBCTemplate + TransactionTemplate on several projects where hibernate was causing more problems than it solved. Hand crafted joins are pretty easy to do.
Some symptoms that I've seen in multiple projects:
- requests are slow because every request triggers dozens to hundreds of joins.
- overuse of the @Transactional annotation (spring/hibernate) because of developers slapping it on anything that looks like it might be doing anything with a database while neither understanding transactional semantics or aspect oriented programming (which causes some funny behavior)
- Attempts to implement class inheritance via database tables and corresponding hacks and complexity to query because of that.
- Lack of a coherent database design. IMHO, a good use of ORM should start with a good old database design. A 1 to 1 mapping of your domain to tables is typically not it.
- Over and under use of database constraints, indices, etc. because of a lack of knowledge of how databases actually work resulting in unenforced referential integrity constraints, poor performance, and weak transactional semantics.
I've used lots of different styles of databases over the years. I generally break things down into:
- simple key value stores like redis, memcached, etc.
- document databases like couchdb, elasticsearch. These tend to have schemas and fields
- SQL databases (mysql, postgres, mssql, oracle, ....)
- Nosql object databases (mongodb, firestore, etc.
I tend to mix these styles and would happily use postgres as a document store. IMHO if I'm not going to query on it, putting it in separate column adds little or no value. If I am going to query on it; it should have an index.
Years of using document stores have taught me the value of de-normalizing stuff like user names and other things that rarely change but are a part of pretty much everything. I've ripped out hibernate in favor of JDBCTemplate + TransactionTemplate on several projects where hibernate was causing more problems than it solved. Hand crafted joins are pretty easy to do.