FUDforum
Fast Uncompromising Discussions. FUDforum will get your users talking.
Home » Imported messages » comp.lang.php » ORMs comparisons/complaints.
Show: Today's Messages :: Polls :: Message Navigator
Return to the default flat view Create a new topic Submit Reply
Re: ORMs comparisons/complaints. [message #184463 is a reply to message #184455] Thu, 02 January 2014 11:36 Go to previous messageGo to previous message
Silvio is currently offline  Silvio
Messages: 5
Registered: December 2013
Karma:
Junior Member
On 01/02/2014 04:19 AM, Arne Vajhøj wrote:
> On 12/30/2013 8:38 AM, Silvio wrote:
>> On 12/30/2013 05:27 AM, Arne Vajhøj wrote:
>>> On 12/23/2013 7:25 AM, Silvio wrote:
>>> Most places they are actually able to get ORM working.
>>>
>>> I am not quite sure that I can follow you.
>>>
>>> If you want OO for the code and you want the relational database,
>>> then you must do a mapping between the two.
>>>
>>> You can either hand write a lot of code or use an ORM.
>>>
>>> Typical using an ORM is faster because it means less code.
>>>
>>> You may not be able to use ORM 100%, but then use it 90% and
>>> hand write code for the remaining 10%.
>>
>> ORMs are good at what they where invented for: serializing an object and
>> resurrecting it at a later point in time.
>
> Storing objects in a relational database via ORM is very different
> from serialization (for non-trivial usage).
>
> A serialization stores everything in a sequential stream of data.
>
> Storing objects in a relational database via ORM store the stuff
> not already stored in different tables.
>
> Using a document store have some similarities with serialization.
>

I meant serialization in the more general sense. I am not talking about
Object(In/Out)putStream but about saving the exact state of an instance
to some addressable storage with the main purpose of restoring its state
later.

>> That means you have to design
>> your system and its underlying data as a collection of objects with
>> (encapsulated) member data. Using that approach the lifetime of an
>> object instance must be able to extend the actual running span of the
>> program. That requires serialization/resurrection by definition.
>
> No.
>
> It requires the ability to save and load data.
>

No, not data but instances. My point is that these are fundamentally
different.

>> Apart
>> from the fact that I think that this is a bad approach on its own, to
>> constrain memory usage objects need to be put to sleep by default and be
>> resurrected only when they are accessed.
>
> That is how persistence works. The data are on disk and when a program
> needs them they are read from disk to memory.
>
>> This makes the approach even
>> more blurred and needlessly complex, bringing stuff like caching and
>> managing/synchronizing duplicate object instances across concurrently
>> running program instances into the picture.
>
> But that is not in any way ORM specific.
>
> Plain JDBC will have the same potential issues with caching.
>

In theory the ORM approach does not need more caching than a RDBMS
driven approach. In practice this is not the case. The number of cases
where caching outside of the RDBMS is actually needed is very limited
and I rarely use any form of data caching.
Without exception all the ORM systems I worked on relied heavily on
caching or the would not be practically usable.

>> To make things worse almost no system only needs single object
>> instances. Almost any practical system needs counts, averages etc. which
>> could be done with a query on an RDBMS or by traversing object instances
>> IF THEY WHERE REAL INSTANCES. Since doing the latter with an ORM would
>> require resurrecting enormous amounts of instances for practical reasons
>> you have to pour water into the wine and do atypical stuff like joins
>> and aggregate queries through the ORM.
>
> ????
>
> Joins is a core feature of an ORM.
>

You can do joins easily but that is not the big problem. The core
problem is that joins create new views on the underlying data that do
not match with the entity classes that match its underlying tables. To
represent the data from a join properly you would need a new class and
then you get into one of the biggest culprits with ORM: aliased data and
cache redundancy.

>> I know they CAN do this but that
>> is no more than a wart on such systems since they contradict the primary
>> goal of an ORM.
>
> Aggregate functions are not very ORM'ish.
>
> But if they are used much in the transactional work that ORM
> is intended, then something is wrong in the first place.
>

That is just my point. I never encounter any purely transactional
system. That is almost always a part but it is always the easy part.
Also, it's not that ORM tool providers shout from the roofs that you
should only use them for transactional stuff...

>> This is also the area where ORMs failed in the projects
>> I talked about. It's not that the ORM can not do it, it just can not do
>> it sufficiently well even with help from the most experienced experts we
>> could find.
>
> ????
>
> Joins is a core feature of ORM.
>
> And common Java ORM's like JPA implemntations and Hibernate does
> aggregate functions exactly like SQL in JPQL and HQL respectively.
>
> I wonder what kind of "experts" you got.
>
> Arne
>

Yes, they got all the stuff working the first time with joins and
aggregates like you say. But after some time they got into trouble
because aliased data caused the systems to show faulty counts and totals
etc. and from there on it went down-hill. On more than one system they
had to forcefully flush the cache at specific moments to get the right
results for subsequent reporting. Which then did not work very promptly,
to put it mildly.

Most systems I work(ed) on are primarily analytical systems working on
data that comes from surveys, measure devices, order tracking systems
etc. and fetching a record and storing it after manually changing some
attributes is not the common use case. The primary goal is to properly
manage such data at the record level behind the scenes while at the same
time allow thorough analysis of the overall process. Much of this
requires aggregates on joins that have to be built dynamically because
the user can specify exactly what he needs via a UI, akin to an OLAP
system.

I admit that this is not a good match for ORM but in these cases that
was hindsight wisdom. When they started they thought ORM was the right
tool. Which does not surprise me since I encounter many people who never
doubt ORM is the way to go with any system.

Report message to a moderator

[Message index]
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: tracking file usage
Next Topic: Processing accented characters submitted from forms
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ]

Current Time: Mon Nov 25 03:20:54 GMT 2024

Total time taken to generate the page: 0.04248 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.1.3.
Copyright ©2001-2023 FUDforum Bulletin Board Software