3 ms·

The downside of using ORM this way is that it doesn't really solve the interesting cases, or more subtle differences in behaviour. By "interesting cases" I mea

The downside of using ORM this way is that it doesn't really solve the interesting cases, or more subtle differences in behaviour. By "interesting cases" I mean applications that leverage the more unique features in different database systems (like the full-text search implementations, that tend to be very database specific). By subtle differences I mean e.g. specific issues like Oracle handling NULL vs. empty string unlike other databases, or more serious differences related e.g. to locking (so an application that works fine on one database fails spectacularly on another one). Obviously, if you treat the advanced database system as a dumb data store, this may work. But it kinda tends to reduce any database to the worst non-existent database, missing any of the nice features. Because all the advanced stuff is "forbidden" for portability reasons. I've seen so many cases of performance issues where the right solutions were rejected because it would impact portabiliy ...

QueensGambit 8y ago
>> By "interesting cases" I mean applications that leverage the more unique features in different database systems Actually, most ORMs like Hibernate allow you to write native SQL (or even stored procedure) to take advantage of native db features. In that case, you have to trade-off portability, if that feature is important to you. >> or more serious differences related e.g. to locking (so an application that works fine on one database fails spectacularly on another one) Locking (default - READ_COMMITTED) also works consistently across databases. The problem happens only when you introduce distributed ORM cache where data is not updated synchronously across the cluster. It is a reasonable trade-off for performance.
- wtetzner 8y ago
  Something like jOOQ allows you to use the fancy SQL features while still keeping portability.
moriarty-s3a 8y ago
It's a tradeoff, though. For 99% of LOB applications the odd details of specific database implementations are irrelevant and can be ignored by even a team of mediocre developers. Most businesses are mostly interested in selling 5-10x the number of licenses for 1.1x the cost. (Or, like the sibling comment pointed out for 0.9x the cost because you can usually ignore much of the annoying boilerplate) Performance frequently is more than "good enough" and in the 1% case where it isn't, most ORMs will let you write custom SQL (or, you can always write it outside the ORM). Sometimes the best and cheapest solution to performance problems is to simply throw more hardware at it. IME, most developers are terrible at writing queries with or without an ORM. There are certainly use cases where ORMs are not appropriate at all but the ability to evaluate your situation and recognize the tools that are appropriate and those that are not is an important skill in the software industry in general and is not limited to ORMs.

QueensGambit 8y ago

>> By "interesting cases" I mean applications that leverage the more unique features in different database systems Actually, most ORMs like Hibernate allow you to write native SQL (or even stored procedure) to take advantage of native db features. In that case, you have to trade-off portability, if that feature is important to you. >> or more serious differences related e.g. to locking (so an application that works fine on one database fails spectacularly on another one) Locking (default - READ_COMMITTED) also works consistently across databases. The problem happens only when you introduce distributed ORM cache where data is not updated synchronously across the cluster. It is a reasonable trade-off for performance.

wtetzner 8y ago
Something like jOOQ allows you to use the fancy SQL features while still keeping portability.

moriarty-s3a 8y ago

It's a tradeoff, though. For 99% of LOB applications the odd details of specific database implementations are irrelevant and can be ignored by even a team of mediocre developers. Most businesses are mostly interested in selling 5-10x the number of licenses for 1.1x the cost. (Or, like the sibling comment pointed out for 0.9x the cost because you can usually ignore much of the annoying boilerplate) Performance frequently is more than "good enough" and in the 1% case where it isn't, most ORMs will let you write custom SQL (or, you can always write it outside the ORM). Sometimes the best and cheapest solution to performance problems is to simply throw more hardware at it. IME, most developers are terrible at writing queries with or without an ORM. There are certainly use cases where ORMs are not appropriate at all but the ability to evaluate your situation and recognize the tools that are appropriate and those that are not is an important skill in the software industry in general and is not limited to ORMs.