3 ms·

Yeah but that sucks though. Imagine being a large company with a multi-million dollar annual spend that could be entirely free if only Postgres had been a bit m

Yeah but that sucks though. Imagine being a large company with a multi-million dollar annual spend that could be entirely free if only Postgres had been a bit more mature back when you started. So many of the decisions you make when needing to move quickly at the start of your growth curve, are the ones that slowly kill you after market saturation. Being able to swap out a db would be nice.

onion2k 4y ago
That's not true though. The answer isn't to use a database abstraction, but to architect your software to make changes straightforward. If you design your code properly (push database queries through a standard set of APIs that are reused everywhere, put queries in their own functions or classes, never put queries in components, etc) then moving to a different database is a relatively simple matter of updating your DB layer. A database abstraction makes people think "I can change my database just by changing the db adapter, so why think about my DB code at all!" That is the problem. You don't need a wrapper that understands the APIs for different databases when you're only using one database. What you need is to think about how you write your code.
- throwaway290 4y ago
  Exactly. It seemed to me as if the author originally thought with a framework they don't ever have to think about the architecture, but of course it's still possible to shoot yourself in the foot and end up with a tangled unrefactorable mess. The article channels misplaced disappointment. Give it some thought and properly encapsulate your core business logic and you won't have that much trouble migrating to another framework or a custom solution if need be (especially easy if your current framework has good documentation, which Django definitely does).
Joel_Mckay 4y ago
Large firms have the resources to overhaul infrastructure, and even with a project failure rate of 54% often manage to complete migrations. Only small shops get hit hard when things go wrong.

onion2k 4y ago

That's not true though. The answer isn't to use a database abstraction, but to architect your software to make changes straightforward. If you design your code properly (push database queries through a standard set of APIs that are reused everywhere, put queries in their own functions or classes, never put queries in components, etc) then moving to a different database is a relatively simple matter of updating your DB layer. A database abstraction makes people think "I can change my database just by changing the db adapter, so why think about my DB code at all!" That is the problem. You don't need a wrapper that understands the APIs for different databases when you're only using one database. What you need is to think about how you write your code.

throwaway290 4y ago
Exactly. It seemed to me as if the author originally thought with a framework they don't ever have to think about the architecture, but of course it's still possible to shoot yourself in the foot and end up with a tangled unrefactorable mess. The article channels misplaced disappointment. Give it some thought and properly encapsulate your core business logic and you won't have that much trouble migrating to another framework or a custom solution if need be (especially easy if your current framework has good documentation, which Django definitely does).

Joel_Mckay 4y ago

Large firms have the resources to overhaul infrastructure, and even with a project failure rate of 54% often manage to complete migrations. Only small shops get hit hard when things go wrong.