3 ms·

But if we use ORMs, they're "services" we can swap, right? Sort of? If we design architectures that hide db access (should it exist) behind a service, better y

But if we use ORMs, they're "services" we can swap, right? Sort of? If we design architectures that hide db access (should it exist) behind a service, better yet. A FOO data service for FOO data and callers don't care how it's stored . . . then it's not heavy, is it? Not that the caller cares about. You're talking actual implementation details before we talk about partitioning responsibility.

Hermitian909 4y ago
> But if we use ORMs, they're "services" we can swap, right? Sort of? That's the dream, but often the answer is "no, not even sort of". Plenty of companies with super smart and experienced engineers laying the DB foundations for a company early in its life have failed at this goal. A few problems come into effect, two immediately spring to mind: 1. Eventually some engineer comes along with a reasonably compelling business case to either pass by the abstraction layer, or extend it so that it's no longer general (e.g. now it only works for Postgres). 2. As the company scales Hyrum's law comes into effect and a thousand pieces of code come to have subtle dependencies on implementation details of the DB. (2) is particularly hard to avoid because DBs are often at least the nominal source of performance bottlenecks and engineers will do almost anything to make performance acceptable no matter how horribly it wrecks abstraction layers.
azurezyq 4y ago
If DB works beautifully, it should not be a problem. But in reality it doesn't. Also DB doesn't live in vacuum, so you are facing these challenges: * ORM bypass, for better performance. * Sharding and application level handling of sharding (making DB not transparent) * Replication (and obviously, delays) And there are always tons of application level code just written because DB just cannot do it efficiently.
bcrosby95 4y ago
Actually abstracting your database would look like taking the lowest common denominator and assuming your database can only support that. Unless you're building a piece of software where database agnosticism is actually a required feature, then I generally find it to be a very poor tradeoff. Databases are incredibly powerful, you should be using them to their fullest extent rather than purposefully handicapping yourself.

Hermitian909 4y ago

> But if we use ORMs, they're "services" we can swap, right? Sort of? That's the dream, but often the answer is "no, not even sort of". Plenty of companies with super smart and experienced engineers laying the DB foundations for a company early in its life have failed at this goal. A few problems come into effect, two immediately spring to mind: 1. Eventually some engineer comes along with a reasonably compelling business case to either pass by the abstraction layer, or extend it so that it's no longer general (e.g. now it only works for Postgres). 2. As the company scales Hyrum's law comes into effect and a thousand pieces of code come to have subtle dependencies on implementation details of the DB. (2) is particularly hard to avoid because DBs are often at least the nominal source of performance bottlenecks and engineers will do almost anything to make performance acceptable no matter how horribly it wrecks abstraction layers.

azurezyq 4y ago

If DB works beautifully, it should not be a problem. But in reality it doesn't. Also DB doesn't live in vacuum, so you are facing these challenges: * ORM bypass, for better performance. * Sharding and application level handling of sharding (making DB not transparent) * Replication (and obviously, delays) And there are always tons of application level code just written because DB just cannot do it efficiently.

bcrosby95 4y ago

Actually abstracting your database would look like taking the lowest common denominator and assuming your database can only support that. Unless you're building a piece of software where database agnosticism is actually a required feature, then I generally find it to be a very poor tradeoff. Databases are incredibly powerful, you should be using them to their fullest extent rather than purposefully handicapping yourself.