Re: ORMs comparisons/complaints.
On 12/31/2013 5:12 AM, Marcel M?ller wrote:
On 30.12.13 05.17, Arne Vajh?j wrote:
You see, I am not really a friend of ORM. If a relational data model
does not fit your needs, you first should consider to use a non
relational database, rather than to normalize the data model to fit into
a relational DB, and use an ORM to hide that from the application layer.
Yes and no.
If you could get non-relational databases with same transactional
support, same tools, same vendor support etc..
And if all access to the database is OO based.
Then that would be obvious.
But the non-relational databases has not reached the same maturity level
(as a summary term for the above) as relational databases.
You are right. We are in an intermediate situation where relational DBMS
are integrated into backup, service and management processes by far
better than the new OO or document based DBMS. And of course, the
administrators have experience with them.
Because of this I did the last larger project still with MSSQL (in
snapshot isolation mode). But the data model did not depend on the DB. I
simply store XML documents with revision information. In fact the DBMS
backend was activated about 4 month after the project started. So when
the time is come we could easily move to Mongo or whatever.
XML in either XML or CLOB columns is one way to combine the operational
advantages of the RDBMS with a NoSQL approach to data.
But you will still lack in tools support. No support from reporting
software. And no tools for adhoc work - you will need to code everything.
What I miss by far more is a standard, how to use NoSQL DBMS. So anybody
writes its own framework with its own advantages and disadvantages.
It is rather chaotic now. Many incompatible libraries. And some of the
libraries are of bad quality.
There are some attempts to remedy that in the Java world. Many
JPA providers are starting to support NoSQL databases.
Even though JPA is intended as an ORM then it can be made to work
with NoSQL databases as well.
And it is a standardized API.
MS could do the same with EF if they wanted to.
And it is common to have the same databases used by modern OO based
software also to be used by non-OO legacy software (like 20 year
old COBOL programs).
COBOL, dark chapter - from the present point of view. And SAP extended
the COBOL style by ABAP.
Legacy stuff is a reality whether we like it or not.
It should be mandatory for developers writing code using ORM to do some
testing with the logging of actual SQL statements executed turned on. It
reveals what is going on without having to know so much about the inside
of the ORM.
Well, true, but from the programmers point of view, I do not always want
to go that deep into the framework. This is like digging down to the
assembler level in former times.
However, at least when doing function programming (without a functional
language) performance checks have to be done by some means or other. As
rule of thumb the number of queries placed on the backend should be
finite on each user interaction, i.e. no queries in a loop. If you
follow this rule reasonable indices and the optimizer can do their job
It is like many other things.
One write some readable code.
If performance test shows a real performance problem then one
If one is using an ORM, then checking what SQL it generates is
an obvious first step.
Of course, if you are stuck with an SQL DB for some reason and you need
to adapt to an OO application layer ORM might be a choice. But if the
data model in the DB is not intended for ORM usage, you won't get happy,
because there are almost always properties of the data model that are
not correctly modeled in SQL.
It seems as if very large parts of the Java, .NET and Ruby worlds
are able to make it work.
There is always a way (with unlimited resources :-) ). But the question
is about maintainability and TCO. And the answer is not always clear.
Even small bugs or missing features in the ORM layer may result in
fragile workarounds that collapse on small code changes.
I would prefer when the investigation of standards around NoSQL over
driving ORM to the limits. The first has a future, the latter is an
intermediate solution. Of course, both have their places for now.
I doubt that relational databases will go away.