Hacker News Reader

Comment by joppy | Hacker News Reader

How big of a concern is this? Nowhere I’ve ever worked has been concerned with the ability to swap the database for a completely different one, in the same way they are not concerned with the ability to swap whatever programming language is being used for a different one.

View on HN

I worked for an organization that used Oracle for relatively trivial applications. The difficulty of switching to MySQL and then later to Postgres convinced them to use an ORM going forward.

Basically if your app might last 20 years (this one went online when I was 4) it might be a consideration.

IME if you didn’t use the DB -specific features, migration is painful, but not that much so.

If you did use the DB specific features, you’re screwed regardless of an ORM.

NB: I work for a DB migration firm, specializing in legacy->modern — where our usual customer has thousands of SP’s that have to be migrated and an ORM would have saved you maybe 5% of the effort; so my experience is biased towards that level of difficulty.

TSQL and PSQL ideas of a stored procedure are not really the same.

If your SQL is mostly bound columns or some sort of ORM only then you can get lucky and just play the data type matching game. But most of the ones I have ever had to port was playing the 'rewrite these 300 stored procs again' game. They usually ended up in some sort of stored procedure for one of a few reasons 'they only knew how to do that', performance, that is what the senior guy wants.

In a type-safe environment I think you should just be able to switch your pur sang SQL builder to another dialect. Because of the type-safety you’ll be able to find incompatibilities at compile time which makes the migration easy enough (ignoring data migration). This avoids creating a weird ad hoc SQL dialect trying to fit all the others in a single API.

I work on Mammoth which is a pur sang Postgres query builder, see https://github.com/Ff00ff/mammoth.

Reply on news.ycombinator.com