Hacker News new | comments | show | ask | jobs | submit login

my take on hibernate, or ORMs in general, is really to abstract the _differences_ between vendors' sql implementation (including creation, and upgrading of schema). If you have to ship a product that have to work under all database vendors, an ORM like hibernate is the only choice - otherwise, you'd have to write separate scripts for each vendor, and that just makes the job at least 5x harder (or more, assuming you go for more vendors).

Not kwowing how to write proper SQL is a problem, and ORM won't solve that for you.




Doesn't seem like that common of a problem to have to ship code that has to work with different databases. But if I ever had to do such a thing I would just stick with ANSI SQL.


There's no such thing as ANSI SQL for real world applications on real world databases. Even something as simple as limiting the number of rows returned varies widely (TOP vs LIMIT vs rownum).

The correct answer is to forget about database independence and double down on just one[1] so you can use it to its full potential.

[1]: And obviously it should be Postgres...


and you missed "fetch first" which is the ANSI thing


> common of a problem to have to ship code that has to work with different database

when you are not writing a SaaS, but shipping a piece of software for a customer to run on their own server, it's a very common use case to support different database vendors - especially in enterprise software.


Generally the database to use is dictated by the software, that or it will support one or two, not any database.


It's useful to, for instance, run your test suite against an in-memory database like sqlite or hsql, but use a "real" database in production.


I think using VMs or something like Vagrant is a much better solution to that problem. You generally don't want to test against something that's drastically different than what you run in production.


If at all possible, you should choose one DBMS and stick with it.

There are non-abstractable differences once you no longer have a toy project, e.g. locking and isolation semantics.

There might be some valid reason for making your applications talk to different DBMS, but you have a tough slog ahead no matter how you do it.


> If at all possible, you should choose one DBMS and stick with it.

Yeah, sure, go tell that to your manager who promised multi vendor compat to your clients.

Problems with the ORM nowadays always stem from developers who are ignorant of SQL. Those people should not be working for you anyway.


> go tell that to your manager who promised multi vendor compat to your clients

Okay, I'll tell him that 5x the systems means more work, possible bugs, etc. Seems logical.

I'll tell him the same thing if he promises Windows, Mac, Linux, Solaris, and Plan 9 compatibility.

I'm not saying you shouldn't be able to use the same application with several databases; I'm saying you should avoid it.


Why don't you write your code so you don't have to choose a compiler vendor or runtime? Java today, Rust tomorrow!




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: