There is a paradox in the nature of the abstractions that many developers want when dealing with databases. They will strain at the gnat, but swallow a camel (Matthew 23:24). Whereas they will recoil with horror when a DBA suggests that an abstraction layer based on views, functions and procedures in a separate database schema would decouple application-development work from database-development work, they tend to find the appeal of an Object-Relational Mapper (ORM) irresistible.

 There are, of course,  enough implementation differences between different RDBMSs, and the flavors of SQL that they support, that s level of abstraction is an obvious need and desire among developers, In fact, ODBC has always provided a common denominator of SQL compliance, even with databases based on simple text-files. Whilst this can provide a SQL interface to a large variety of data sources, it misses the point: developers would like to avoid SQL altogether, since it requires them to be familiar with the relational model of their data as well as the Object model. Over time, there seems to have grown an increasing hope or expectation that an Object Relational Mapping tool is a route to a pure and clean abstraction of the database, within the object domain model. It will smoothly translate their domain models into perfect relational data models, and retrieve and modify "state" in their data layer without them having to write a word of SQL.

It won't, and of course these hopes have been largely thwarted. Tellingly, in response to a recent ORM-related article, Gavin King (creator of Hibernate) reveals that the leakiness of ORM abstraction is in fact a feature, not a bug, since "both the object model and the relational model are valid ways of looking at the data, and both are useful". He recounts visiting client sites where his main role was to "give the team permission to use SQL for a problem that was clearly unsuited to ORM".

Ultimately, ORMs, while fulfilling a useful purpose in providing an application level description of the relational data model, will never obviate the need  for a firm understanding of how to write SQL, or for the team to apply the same thought and care to the design of the database and distribution of the data as they do to any other later of the application.