3 ms·

It's "Active Record" style ORMs like Hibernate that are the culprit, and the way many developers utilize them to avoid any contact with the realities of RDBMs w

It's "Active Record" style ORMs like Hibernate that are the culprit, and the way many developers utilize them to avoid any contact with the realities of RDBMs which leads to data access antipatterns which lead to poor performance (multiple needless queries per request etc.). Another thing people need to really give up on is the pipe dream of switching databases -- you're not going to do it. I've never seen one single case of people actually utilizing ORM to actually change RDBMs they store data in. Not all ORMs are like that and the best solutions are the ones like Knex/Objecion where an ORM (Objection in this case) is nice abstraction for single-object access/writing and underlying SQL builder (Knex) is fully exposed and used for everything else.

rickycook 9y ago
i’d agree switching a current project from DB server to a different on is a pipe dtream, but the couple of use cases that are related but incredibly handy are switching DB driver mid project for any number of reasons, or using a new and unfamiliar database in a new project
toomanybeersies 9y ago
At my previous job we practically exclusively used Activerecord (the Ruby version), we had maybe half a dozen queries that were hard coded SQL. We also managed to switch from MySQL to Postgres with about 1 minute of downtime on a 16 GB database. This was a reasonably mature codebase, about 3 years old.
NoGravitas 9y ago
I think it's misleading to think about switching databases on an ongoing application as the use case for database independence. More important use cases: 1. Using SQLite for unit testing and a real RDBMS for integration testing, acceptance testing, and production. 2. When you are writing a library that will be used by different projects, not all within a single organization (e.g., a Free Software project). 3. When you are providing a product that the end-user may want to use with different choices of database (e.g. forum software, Nextcloud, etc.)

rickycook 9y ago

i’d agree switching a current project from DB server to a different on is a pipe dtream, but the couple of use cases that are related but incredibly handy are switching DB driver mid project for any number of reasons, or using a new and unfamiliar database in a new project

toomanybeersies 9y ago

At my previous job we practically exclusively used Activerecord (the Ruby version), we had maybe half a dozen queries that were hard coded SQL. We also managed to switch from MySQL to Postgres with about 1 minute of downtime on a 16 GB database. This was a reasonably mature codebase, about 3 years old.

NoGravitas 9y ago

I think it's misleading to think about switching databases on an ongoing application as the use case for database independence. More important use cases: 1. Using SQLite for unit testing and a real RDBMS for integration testing, acceptance testing, and production. 2. When you are writing a library that will be used by different projects, not all within a single organization (e.g., a Free Software project). 3. When you are providing a product that the end-user may want to use with different choices of database (e.g. forum software, Nextcloud, etc.)