ORMs comparisons/complaints.

[Jerry Stuckle]

It is what the application is using to connect to the database - that
is connectivity.


If the charter said that only what is covered in the PHP manual is
on topic, then ORM was definitely off topic.

But it does not. It includes database connectivity without making
any restrictions on it being included in PHP and/or being documented
in the PHP documentation.

That means that PEAR DB stuff, ORM etc. are on topic.

Live with it or get the charter changed.


Said the person that considered ORM's to be applications.

Arne

The OP was asking about ORM packages. That is NOT "database
connectivity". But you're too stoopid to know the difference.

Applications and packages are best known by the people who wrote them;
second are people are use them. Neither are present on comp.lang.php.

But then you, who have never been on c.l.p., think you know better than
the regulars who have been here for years. How like the TROLL you are.


--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
(e-mail address removed)
==================

 

[Jerry Stuckle]

If it is what the PHP code is using to access the database, then
it is providing database connectivity.


Name calling is not a very convincing argumentation.

Arne

The truth hurts, doesn't it?


--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
(e-mail address removed)
==================

 

[Ricardo Palomaes]

El 30/12/13 14:04, Jerry Stuckle escribió:

ORM is not database connectivity. But you're too stoopid to
understand the difference. Just like some other Java programmers.

NOW it is clear who's the troll.

 

[The Natural Philosopher]

El 30/12/13 14:04, Jerry Stuckle escribió:


NOW it is clear who's the troll.

what took you so long...

--
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to
lead are elected by the least capable of producing, and where the
members of society least likely to sustain themselves or succeed, are
rewarded with goods and services paid for by the confiscated wealth of a
diminishing number of producers.

 

[Jerry Stuckle]

what took you so long...

Ah, the anonymous troll speaks up again! He's afraid to use his real
name because he doesn't want us to find out he's neither a programmer or
the electrical engineer he claims to be.

And he doesn't like me because I've caught him too many times in his lies.


--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
(e-mail address removed)
==================

 

[Doug Miller]

Name calling is not a very convincing argumentation.

No, of course not, but it's the norm for Jerry whenever someone dares to disagree with him.

Just do what most of the rest of us who've been around this group for a while have already
done long ago: killfile him, and move on with your life.

 

[Arved Sandstrom]

The topic is unlikely to fit to php. F'up to java only.


First of all you need to mention what ORMs are designed for. They are
intended to make SQL databases suitable for OO programming style and/or
non-relational data models. At the end OO expressions are turned into
SQL and then to an execution plan.

Do ORMs "make SQL databases suitable for OO programming style"? In the
sense that an ORM presents tuples derived from RDBMS data as OO
programming language objects, that's true. But those initial datalayer
objects are frequently PODSs, or very close, and a number of OO styles
advocate keeping datalayer objects as essentially bundles of fields with
accessor methods.

As to the other main function of an ORM, which is to present a
supposedly simpler way of accessing an RDBMS than JDBC, I think it's
arguable as to whether any of that exemplifies high levels of the OO
art: most of it (not just in Java) looks pretty procedural to me.

From that you can see that there is exactly one thing superfluous in
this scenario: SQL. It is the bottleneck where all expressions must fit
to. But it does not add any functionality, quite the contrary. It is
just a emulation level for compatibility, like a SATA adapter enables a
SATA drive to be used with an IDE port.

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.

I'll posit that a relational data model does very often fit. We've just
had a few generational cycles of young bucks who are trying to make
their name by challenging something that works. Use a non-relational
model when you've knowingly proved that there is no way of making your
data fit relational - don't jump on non-relational because it's
currently cool.

ORMs are known to slow things down. I don't think that this is true in
general.

Err, if it's not true in general, then it's maybe not usually true? So
it's "known" by whom?

But the ORM layer makes some trivial looking expressions

amazingly complex. So it is not that easy for the programmer to estimate
the complexity of a code block, without knowledge about the entire ORM
layer and the base data model in SQL. In fact I have redesigned many
code parts because of this.

That's why they pay us professional programmers big bucks. Simplifying
complex when the complex can be simplified.

I've rarely seen ORM code get more complex than NoSQL, ISAM/VSAM, or
direct flat file operations. Unless a programmer is getting cute, or is
incompetent.

There is one advantage. Adding attributes to the data model is quite
simple with an ORM. No need to do redundant changes at many locations.
But any document DB will provide this as well without the need for SQL
and an ORM.

By regarding your data as being document-oriented you already made a
fundamental decision that your data is semi-structured or
non-structured. Good luck with that: I've seen a few recent startups
fail because they thought that.

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.

And most people who seize on a NoSQL solution were probably never
"stuck" with an SQL DB, they just got sucked in by the hype. I've heard
way more stories about projects where folks had to program
relational-like logic on top of a NoSQL DB to solve their problems than
I've heard anecdotes about people not being able to make things work
with an RDBMS.

However, to get more detailed information you need to phrase your
questions more precisely. What are your topics of interest? Performance?
Maintainability? What kind of data model do you intend to use? Many
entities? Or many properties? What kind of relations? Polymorphism?


Marcel

AHS

 

[Arved Sandstrom]

I don't like ORM utilities much because they rarely model all of the
complex relationships and behaviors, for better or worse, that may exist
in SQL. You end up spending at least as much time working around those
limitations as time initially saved.

Simpler data works fine in ORM, but simpler data is isn't the complex
task ORM tries to solve.

That leaves many ORM utilities as too enormous, too complex, too slow,
and still a poor fit for SQL. I see ORM as potentially being an
excellent fit for document stores but I have little experience with
those.

To echo Arne's comment, an "excellent fit for document stores"??? How
so? If the document is well-modeled by a relational calculus, why model
it as a document? The current notion of a document is that of groups of
semi-structured or non-structured data that don't necessarily adhere to
any schema. Which is non-relational. There are fundamental differences here.

I haven't encountered the problems you have, apparently, with ORMs. Data
is complex, relational data is obviously just as complex, and any method
of querying or manipulating real relational data is often hard. And
considering major ORMs (not just Java), and the amount of educated
effort that has gone into them, there are not many people who are
well-advised to routinely use SQL directly if they have other
options...not unless they are RDBMS specialists, and that's what they do
for a living. Are you one? I'm not.

I'll say this: Java language limitations have hurt Java ORMs, and it's
not the fault of the ORM developers: I know a few of them. The JPA
Criteria API is a sign of the apocalypse. It's unfortunately informed by
folks who are both struggling with Java limitations and have experience
with native implementations. C# LINQ and Scala Squeryl are conceptually
light years ahead of Java ORMs.

AHS

 

[The Natural Philosopher]

Data is complex, relational data is obviously just as complex, and any
method of querying or manipulating real relational data is often hard.
And considering major ORMs (not just Java), and the amount of educated
effort that has gone into them, there are not many people who are
well-advised to routinely use SQL directly if they have other
options...not unless they are RDBMS specialists, and that's what they do
for a living. Are you one? I'm not.

Ah. So mining is complex and labour intesive, so lets not learn how to
use an excavator, but instead develop tools to allow us to organise huge
gangs of navvies with picks and shovels, because that's easier for us
lazy shits than mastering the controls on a dump truck or draglinme
excavator.

If you cant manage relational databases, you shouldn't be messing with
big data.



--
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to
lead are elected by the least capable of producing, and where the
members of society least likely to sustain themselves or succeed, are
rewarded with goods and services paid for by the confiscated wealth of a
diminishing number of producers.

 

[Silvio]

[snip]
This is one approach. I think one of the major "features" of most ORM
implementations is that they attempt to abstract away the actual RDBMS
layer to the point where you feel "dirty" trying to access it in any
meaningful way. This does provide some value in portability, but many
applications rarely need this portability of RDBMS, and more often
benefit from special features of the particular RDBMS chosen.

Portability across RDBMS-es is far more often planned for upfront than
it is actually used. But if it is really desired it can easily be
achieved in the data access layers. Not exactly rocket science, I have
done it in many systems.

Treating the data store as a separate deliverable gives a much more
important type of flexibility: being able too swap out (parts of)
applications that access the data since their interaction with that data
is well defined instead of an implicit artifact of the applications
themselves.

 

[Arved Sandstrom]

Ah. So mining is complex and labour intesive, so lets not learn how to
use an excavator, but instead develop tools to allow us to organise huge
gangs of navvies with picks and shovels, because that's easier for us
lazy shits than mastering the controls on a dump truck or draglinme
excavator.

If you cant manage relational databases, you shouldn't be messing with
big data.

Identify yourself by your real name, doorknob. Maybe then you can put up
or shut up.

Learn spelling and grammar too - those skills help when you converse
with adults.

AHS

 

[Marcel Müller]

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.

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. I.e.
we had to write a query optimizer and an index provider. Things that
relational DBMS have at a highly optimized level. Unfortunately they are
almost unusable if the data model does not fit to them. And with ORM
often only a few aspects of the DBMS performance reach the application
level. Others mainly help to solve the problems that did not exist before.

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.

[performance]

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
usually.

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.


Marcel

 

[The Natural Philosopher]

Identify yourself by your real name, doorknob. Maybe then you can put up
or shut up.

Learn spelling and grammar too - those skills help when you converse
with adults.

So no counter argument, just an ad hominem attack.

You are Jerry Stuckle and I claim my $5.

AHS

--
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to
lead are elected by the least capable of producing, and where the
members of society least likely to sustain themselves or succeed, are
rewarded with goods and services paid for by the confiscated wealth of a
diminishing number of producers.

 

[Jerry Stuckle]

So no counter argument, just an ad hominem attack.

You are Jerry Stuckle and I claim my $5.

ROFLMAO! This has got to be the stoopidest post you've ever made. And
you've made some pretty stoopid ones!


--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
(e-mail address removed)
==================

 

[Arved Sandstrom]

I did several stabs at ORMs in some small toy projects but have mainly
use ORMs working on existing projects using ORMs (both Hibernate and
Toplink) that where performing extremely poorly and had become almost
impossible to maintain and extend. I was then called in to take the ORM
out of the system as much as possible. This always consisted of creating
alternative tools for interacting with the RDBMS that the programmers
could use to rewrite the must critical and/or problematic system parts.

So you could say I have mainly negative experiences I could share. To
put it bluntly: I think ORM is a bad idea in general. I dig OOP for
modelling the transient behaviour of a running program but find the
relational model far superior for modelling data. I also find it
beneficial in general to think of data and programs working on data as
separate things.

ORM is a mechanism to help you do it the other way around, and a poor
one at it. If you want to persist objects use an object database or
serialize to some NoSQL store. If you want structured data in an RDBMS
don't degrade it into a pile of persisted objects.

Silvio

I also find the relational model very useful for modeling data: usually
better than other models. As I noted in another post, ORMs don't
typically distance a programmer that much from relational concepts: they
simply hide some of the mechanics. If you want to routinely use JDBC and
manually construct objects, feel free - I like having libraries doing
some of the heavy lifting.

The last sentence of your last para is remarkable. I'd be interested to
know why an object (a class instance for class-based OO) is a poor
representation of data in a RDBMS. You might as well state that a C
struct or a Haskell data type is unsuitable for that purpose.

If I want to access structured data in an RDBMS, and I am writing in an
OO language (not an uncommon requirement these days), I think I'll use a
semblance of an ORM. I'm reluctant to write assembly language to
manipulate data...not in 2013.

If you had mainly negative experiences with ORMs, Silvio, and I'll take
your word for it, then perhaps your colleagues were inept or incompetent
or lazy. I've experienced the same problems you described, many times:
come to find out that the performance problems were human and needed to
be fired.

AHS

 

[Marcel Müller]

Do ORMs "make SQL databases suitable for OO programming style"? In the
sense that an ORM presents tuples derived from RDBMS data as OO
programming language objects, that's true. But those initial datalayer
objects are frequently PODSs, or very close, and a number of OO styles
advocate keeping datalayer objects as essentially bundles of fields with
accessor methods.

If I use ORM I expect that it can reasonably deal with deep structures.
Normalizing the data model at object level is exactly not what I want.

As to the other main function of an ORM, which is to present a
supposedly simpler way of accessing an RDBMS than JDBC, I think it's
arguable as to whether any of that exemplifies high levels of the OO
art: most of it (not just in Java) looks pretty procedural to me.

Hmm, you see ORM not as a function extension but simply as a more
convenient API to RDBMS. That's OK. But maybe _O_RM does not hit the
nail on the head in this case.

I'll posit that a relational data model does very often fit.

Well, maybe it fits because we mostly think in solutions rather than in
requirements. This applies already to the customer requests. It is often
difficult to distinguish between real requirements and creative ideas of
the customer, how to solve his issues.

If you get two steps back, then there are quite often requirements that
do not fit well into RDBMS. I.e. I had almost no project where not at
least one property of some object had a 1:n relation. I do not talk
about classical relations like costomer-supplier here - they fit well
into RDBMS. I talk about properties that can have more than one value.

Case #1: enumeration types with multiple selections.
To put them into a RDBMS you need either
a) introduce a new table,
b) serialize them into a string or bit vector or
c) put each value into a separate column.
Each choice has it's disadvantages. a) adds complexity to SQL (many
JOINs, difficult updates - OK, here ORMs can really help) and has a
large overhead for small integral types, because of the foreign keys and
the row management of the DBMS. c) and b) only works if the number of
different values is finite by design. b) cannot be reasonably indexed.
c) makes it really complicated to add a new value.
Within a OO data model I simply add an array or a set to the class and I
am done.

Case #2: multiple values without a limited set (e.g ingredients, allergens)
Here can only use solution a) from above in the RDBMS. If you have a
dozen properties of this type things get really worse. Or you end up with
d) a transposed data model.
But d) is even worse with respect to indices and does not provide type
safety because the RDBMS can't handle polymorphism directly.
I also have seen solutions with
e) one transposed table for each data type.
Now the RDBMS is finally raped.

We've just
had a few generational cycles of young bucks who are trying to make
their name by challenging something that works. Use a non-relational
model when you've knowingly proved that there is no way of making your
data fit relational - don't jump on non-relational because it's
currently cool.

Of course, that's always true.

But from my experience success is not manly a question whether you have
gone one way or the other. It is more a question if you have done this
well and in you have enough experience with the tools you are using.

Err, if it's not true in general, then it's maybe not usually true? So
it's "known" by whom?

I think, I used the wrong wording. Let's call it a preconception.

By regarding your data as being document-oriented you already made a
fundamental decision that your data is semi-structured or
non-structured.

Well, an XML is a document too, and most of the time it is well structured.

And most people who seize on a NoSQL solution were probably never
"stuck" with an SQL DB, they just got sucked in by the hype. I've heard
way more stories about projects where folks had to program
relational-like logic on top of a NoSQL DB to solve their problems than
I've heard anecdotes about people not being able to make things work
with an RDBMS.

I do not really have experience with NoSQL databases. But I used non
relational data models and in memory computing now for about 6 years in
different projects. None of the projects failed, all are still live.
Also we did not really save resources because of the decisions made. But
from the code maintenance and from the performance point of view it was
successful. Some change requests to the first of these projects were
implemented by an apprentice in half an hour. This would have taken a
few days by a qualified programmer, if we had chosen a relational data
model.

In the last project - a larger one - we have significant performance
benefits. There is an adjacent third party application with a very
similar data model from the customers point of view. (They are better
with respect to inheritance, we are better with respect to deep
structures but both can deal with polymorphism, table properties an so on.)
They ended up with solution d). We use XML documents. Measurements show
about three orders of magnitude performance difference, measured in time
per object access. We have two CPU cores with <30% load if users make
traffic. They have 16 CPU at 80-100% load if users make traffic. The
number of objects and attributes is comparable. In fact the data is
partially synchronized by interfaces. Both are Web applications. The
number of users is comparable.
OK, they have chosen PHP (used in an object oriented way), we have .NET
3.5. But this will not explain all the 3 orders of magnitude. Their
system creates heavy load on the large attribute values table.


Marcel

 

[Evan Platt]

It should be their not there.

ORM's are great to get something fairly simple of the ground

It should be off not of.

fairly fast. From then on any meaningful feature updates

There should be a comma after on.

that requires work in the data layer makes using an ORM
a real PITA.

Things like, slow performance, hassles when trying to relate

There should be no comma after like.

data between tables, trying to sort out what I want the
SQL to do then all the time it takes to sort out all the
ORM annotations and code and test to satisfy the ORM makes
using the ORM a maintenance headache.

My head hurts reading that run on sentence.

It's a slower coding startup to use straight JDBC but over
time maintenance time and difficulty are linear conststant
with using straight JDBC. Performance is always at a
maximum too.

So when I can, I avoid ORMs completely.

If you're going to nitpick someone's spelling / grammar, make sure
your post is in order

 

[Arved Sandstrom]

It should be their not there.

ORM's are great to get something fairly simple of the ground
fairly fast. From then on any meaningful feature updates
that requires work in the data layer makes using an ORM
a real PITA.

Things like, slow performance, hassles when trying to relate
data between tables, trying to sort out what I want the
SQL to do then all the time it takes to sort out all the
ORM annotations and code and test to satisfy the ORM makes
using the ORM a maintenance headache.

It's a slower coding startup to use straight JDBC but over
time maintenance time and difficulty are linear conststant
with using straight JDBC. Performance is always at a
maximum too.

So when I can, I avoid ORMs completely.

Have you worked in the programming industry for more than say 5 years?
No point you made actually made much sense. I must admit, I've heard a
few guys just 3 years out of uni who style themselves as technical
architects or senior consultants who opine like this.

Your observations wrt JDBC vs use of an ORM are not borne out by
experience. A fair few knowledgeable people have decided that Java ORMs
make sense: I happen to believe that they are correct - ORMs are
complex, and JDBC is more complex, and not very many coders are truly
adept at SQL.

And "performance is always at a maximum"? JDBC versus ORMs? How so? Just
about 99 percent of the people who write Java ORMs are intimately
familiar with JDBC and SQL - I happen to know a few of them. I
respectfully suggest that if you're having performance problems or can't
solve relational calculus, it's not an ORM problem.

AHS

 

[Arne Vajhøj]

ORM's are great to get something fairly simple of the ground
fairly fast. From then on any meaningful feature updates
that requires work in the data layer makes using an ORM
a real PITA.

That sounds weird.

Let us say that you need to add a field.

With an ORM you only need to update:
* one dataclass
* one mapping of data

With plain JDBC you need to change:
* one data class
* N SQL statements
* N places in the Java code

ORM should be a lot simpler.

Things like, slow performance,

You should execute the same SQL with and without ORM - the
only overhead is the extra processing in the ORM, which
should be insignificant compared to actually getting the
data from the database.

hassles when trying to relate
data between tables,

That is a standard feature in all modern/common ORM's.

trying to sort out what I want the
SQL to do

With an ORM you would typical not use SQL.

then all the time it takes to sort out all the
ORM annotations and code and test to satisfy the ORM makes
using the ORM a maintenance headache.

It is fewer changes than plain JDBC.

Arne

 

[Arne Vajhøj]

I'll say this: Java language limitations have hurt Java ORMs, and it's
not the fault of the ORM developers: I know a few of them. The JPA
Criteria API is a sign of the apocalypse. It's unfortunately informed by
folks who are both struggling with Java limitations and have experience
with native implementations. C# LINQ and Scala Squeryl are conceptually
light years ahead of Java ORMs.

Much cleaner syntax.

But I am not convinced that the syntax is sufficient important
to translate that into "light years ahead".

Arne