2 ms·
I believe “database independence” is an anti-pattern in 99% of the cases. Abybody with me? I’ve had great success by not using a database abstraction layer: -
by marhee 2y ago
I believe “database independence” is an anti-pattern in 99% of the cases. Abybody with me?
I’ve had great success by not using a database abstraction layer:
- you can invest the time you spend on being a generalist on many databases to be a real expert on one
- no more fighting the abstraction layer; use any persistence feature directly
- better perfomance is easier to achieve
- simpler data modelling and execution
- simpler backups
The list goes on tbh.
Drawbacks? Well yes: you have to make a really good decision on your dbms (hint: psql).
But that’s actually an advantage deguised as a drawback: wanting to be able to easily change the dbms is just fearing making decisions. It’s like requestibg a car where you can swap out any type of engine.
(Also, use a single dbms. Really. There’s nothing any nosql can do that psql/mysql can’t do (mayve vice verca) unless maybe in really specific cases).
- pydry 2y agoThe level of coupling should reflect the level of investment you're willing to make in a technology. Im also pretty happy to couple to postgres but if im working with mongo id always like an abstraction layer to let me swap out mongo one day. Ive only once wanted an abstraction layer to swap out postgres and that's because i was forced to use azure and azure postgres appeared to be deliberately crippled in order to encourage people to switch to ms sql server.
- ahoka 2y agoThe usual problem is those are never real abstractions, but barely indirections.
- karmakurtisaani 2y agoJust wait until your successor lets the choice of db leak all over the code base, and their successor gets tasked with changing the db to something else decided by the current management. They will be cursing your name until the end of time.