Hibernate and SQL portability

Question

I'm new in persistence and I'm reading the book "Pro JPA 2". I read that the problems of Java and JDBC pack is that

1. SQL is not portable
2. Tight coupling between Java code and SQL

The irony of JDBC is that, although the programming interfaces are portable, the SQL language is not. Despite the many attempts to standardize it, it is still rare to write SQL of any complexity that will run unchanged on two major database platforms. Even where the SQL dialects are similar, each database performs differently depending on the structure of the query, necessitating vendor-specific tuning in most cases.

My questions are:

1. IS the problem linked with SQL portability is still so critical?
2. As I understand, Hibernate, TopLink and other frameworks also have to create SQL queries from their metadata (annotations). How they arrange the problem linked with SQL portability?
3. Java & JDBC tight-coupling means that developer have to write SQL queries. Do I understand it correctly?

Thank in advance for your responses )

Answer 1

1. Yes the problem is with tight coupling between SQL and code and is very critical to project because if we need to migrate from one database to other without ORM, we need to change all the queries in the application.

2. Hibernate, TopLink and Other ORM Solutions converts your java code into SQL Queries and fires them to the database, but they are more standard and well tested so instead of directly working on Queries we can rely on ORM tools which will convert our code into queries and abstracts us from the complexity. So it is a good idea to use ORM tools instead of directly writing queries.

3. Yes, Java & JDBC tight-coupling means that developer have to write SQL queries directly which are not portable, and at time if the database layer changes you need to change all the queries. Instead if you use ORM solutions you can migrate to any database supported by ORM directly, by just changing some XML or configuration files.

Answer 2

SQL portability will be an issue if you ever need to switch to different database.

It is easy to think that you will never switch but that can be costly. I've been on projects that assumed the database would always be vendor x but later vendor y database was needed also. Lots of painful, tedious, rework was required to make application work with both databases.

I recommend that you always use standard SQL and/or use an ORM tool that writes only standard SQL.

My ORM, sormula, always creates standard SQL. If you've developed an application with sormula, all that is required to switch databases is to change the jdbc jar.