Talking about hibernate and others ORMs, the ORMs evangelists talk about SQL like the assembly language for Databases.
I think is soon to assert this, but I guess can be true on a near future, not sure.
UPDATE: The analogy I was referring means SQL is to assembly what ORM is to C/Java/C#. Of course, an exact analogy is not possible. The question is if in the future, with more powerful computers the developers are going to use only ORM (or ORM like) instead of SQL.
No, however you could possibly say SQL is the C of Databases. They are both procedural and imperative, and data oriented instead of object oriented. And as C its easier to model objects and functionality in higher languages but in the end C is the baseline for performance measures.
Absolutely not.
Assembly language is a very low level language where you instruct the processor exactly what to do, including what registers you want to use etc.
SQL is a very high level language where you describe the semantics of what you want, and then a query optimiser decides how to execute it, so you don't even control what gets executed. It's an extremely powerful and flexible language of which any ORM offers at most a (fairly small) subset.
You'll notice that the .NET framework has introduced LINQ recently which is a way to introduce high level SQL-like constructs into languages like C# and VB. Rather than being like assembler, it's pretty easy to argue that SQL works at a higher level of abstraction than most mainstream programming languages.
No, SQL is itself a high level abstraction layer that is (mostly) database agnostic.
No, relational algebra is the "assembler code" of database.
SQL is the "C code", readable and close enough to the "hardware" to be able to outperform all those other high level languages, provided you know what you're doing :-).
I think no. If ORM is a compelling way to write a program (for the sole purpose of avoiding the "assembly language"), many big database vendors with all their resources would have already provided a non-SQL way to access and store data i.e. using ORM.
SQL is the most elegant and future-proof programming paradigm(declarative) to date. RDBMS vendors can seamlessly plug new functionality to SQL construct. Case in point, pre-MSSQL 2005 you have to loop the data to simulate tree structure access and running total. With MSSQL 2005, without using loops, using the same declarative SQL you can access tree structure data and running total in the most efficient manner.
If we were to put these tree-iterating and running total constructs to ORM, this would incur performance penalty.
SQL is the most important "assembly language" for most programmers. That's why many programmers will still invest on learning these assembly language for the foreseeable time to come.
I think many RDBMS vendors will just augment the SQL syntax rather than introducing ORM-based access to their RDBMS.
I have heard a lot of b*s about impedence mismatch between relational and OO over hte years.
My answer has always been that there is indeed a very big impedence mismatch -- between the niave inflexable "everything is an object and only an object" and the wonderfully flexable and sophisticated "data describes real world things; this data can be combined in different as yet unknown ways to produce mathematicaly provable results".
OO is not the only fruit guys.
If you do only online transaction processing you use only the simple sql statements. Hibernate can generate them for you.
But if you want to do reporting, data analyzing or speedy bulk actions you have to learn SQL, and you often will use the vendor specific SQL extensions. Querying hierarchical data for example is possible when you use vendor specific SQL.
If you want to use SQL properly you have to think in sets, not row-by-row tiny statements. Therefore I say it is the exact opposite of assembler.
It is, in the following sense: an ORM provides a high-level, domain-specific API which emits SQL statements, in the same way that a high-level language creates domain-specific APIs and emits machine-language statements.
I.e.:
However, I don't mean to imply that people will stop using SQL and prefer ORMs, in the same way that people have stopped using assembly and prefer HLLs.
SQL shares some traits with assembly language:
However, unlike assembly, SQL is a high-level, platform-independent language. Also, there is no ANSI/ISO standard for assembly language.
Let's compare writing parallelized SQL with writing parallelized assembler.
This the way to write a parallelized sql statement in Oracle:
select /*+ parallel (e, 4) */ deptno,count(*)
from employees e
group by deptno
Now I wish I could tell you how to write parallelized assembler but I strongly doubt it is as easy as adding something like /+ parallel (e,4) /.
this will never happen. SQL is really a dsl which assembler is decidedly not. Mapping a relational db to an object model is useful but not the only purpose of dbs, that is there orms are a small part of what databases are used for, and therefore sql will always remain the dialect of choice for dealing with dbs!