Hacker News Reader

Comment by RangerScience | Hacker News Reader

> whatever the database engine is I know, but... How often does that flexibility come up? How often do you write code first against one DB type, and then switch to a different that would require a re-write?

It's admirable and fun to think about, for sure, but how much use does that feature actually get?

View on HN

> It's admirable and fun to think about, for sure, but how much use does that feature actually get?

(Lukas from jOOQ here)

Surprisingly, that feature gets quite a bit of use. There are two use-cases (among many others) why our customers choose jOOQ:

- They're using a test database (e.g. H2) and a production database (e.g. Oracle), and things still work very nicely, while staying close to SQL

- They're using a client database (e.g. HSQLDB) and a server database (e.g. SQL Server), and can easily replicate without needing to remember subtle syntax differences all the time.

- They're selling complex products that run on as many databases as DB2, MySQL, Oracle, SQL Server, Sybase and they want to use SQL, because their queries have an average of 10 joins each.

I think the advantage isn't so much the ability to switch, but the luxury of not having to know anything specific about the database you are interfacing with. This is especially useful in heterogeneous environments (like my workplace).

Unfortunately to do any real optimizations or something even minimally complex you have to know the underlying rdbms. For example, techniques that work well in Oracle may not work well in MSSQL. If you throw mysql in there, then you have an entire set of standard sql that simply does not work or works but with horrible performance.

I already said this in another thread, it's not about switching databases in one project, but using the same skillset across projects regardless of the database.

Can you use the same skillset across projects regardless of the ORM, or do you have to standardize on one? Why not just standardize on one database?

I find SQL is pretty portable. You have to learn each server's ins and outs to do performance work, but then, those differences are part and parcel of why there are different servers, beyond basic business-competitive reasons.

ORMs just add a thick layer of fluff over an otherwise (mostly) portable language, where I'm concerned. I rather keep it simple between DBs and apps. If there is gross SQL in the app, make a view or function in the database. It isn't rocket surgery but you do need experienced staff to get it right.

Reply on news.ycombinator.com