7 ms·

Regarding database abstraction, the author writes: "In 10 years, I’ve seen only one business make serious effort to completely swap a fully vested database. And

Regarding database abstraction, the author writes: "In 10 years, I’ve seen only one business make serious effort to completely swap a fully vested database. And when it happened, the “Magic file” did not help." Agreed. I almost embarked on a huge PHP mysqli>PDO conversion, and was advised the opportunity costs were huge and the benefits minimal. Glad I took that advice.

silviogutierrez 10y ago
Conversely, at one point I wanted to start using Postgres' JSONB features, but was running my production app on a MySQL backend. Switching was as simple as: 1. Export all data to fixtures. 2. Change settings.py to use the Postgres drive. 3. Load all data into fixtures. Granted, I was sticking to core Django ORM calls, so I wasn't hard coding any SQL anywhere. And the null ordering does change a little, but the tests caught that. So I was definitely glad that worked out. And have been super happy with postgres.
- bayonetz 10y ago
  >sticking to core Django ORM calls I think that's what made it easy. That's the trade off when you try to build a generic DB access to support the trivial DBMS swap like the article take about -- you end up writing a lowest common denominator of functionality common to all your anticipated DBMSs. I assume Django's ORM let's one do DBMS specific stuff but you happened to not make use of that. I agree with the article, 9/10, don't try writing wrappers just to support the "easy future swap out". Write them if they make the specific technology more palatable to work with. An example I'm my life: Rails' ActiveRecord is just a joy to work with but we would be hurting plenty if we tried to swap out to a different DBMS.
mianos 10y ago
Swapped Sybase to Oracle and others many times in the olden days. Clients bought our in memory trading system but mandated the database. More recently have gone from Mysql to Postgres with Sqlalchemy. Quite easy even with substantial existing code (but not trivial).

silviogutierrez 10y ago

Conversely, at one point I wanted to start using Postgres' JSONB features, but was running my production app on a MySQL backend. Switching was as simple as: 1. Export all data to fixtures. 2. Change settings.py to use the Postgres drive. 3. Load all data into fixtures. Granted, I was sticking to core Django ORM calls, so I wasn't hard coding any SQL anywhere. And the null ordering does change a little, but the tests caught that. So I was definitely glad that worked out. And have been super happy with postgres.

bayonetz 10y ago
>sticking to core Django ORM calls I think that's what made it easy. That's the trade off when you try to build a generic DB access to support the trivial DBMS swap like the article take about -- you end up writing a lowest common denominator of functionality common to all your anticipated DBMSs. I assume Django's ORM let's one do DBMS specific stuff but you happened to not make use of that. I agree with the article, 9/10, don't try writing wrappers just to support the "easy future swap out". Write them if they make the specific technology more palatable to work with. An example I'm my life: Rails' ActiveRecord is just a joy to work with but we would be hurting plenty if we tried to swap out to a different DBMS.

mianos 10y ago

Swapped Sybase to Oracle and others many times in the olden days. Clients bought our in memory trading system but mandated the database. More recently have gone from Mysql to Postgres with Sqlalchemy. Quite easy even with substantial existing code (but not trivial).