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 #184455 is a reply to message #184400] Thu, 02 January 2014 03:19 Go to previous messageGo to previous message
Arne Vajhøj is currently offline  Arne Vajhøj
Messages: 27
Registered: December 2013
Karma:
Junior Member
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.

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

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

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

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

> 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
[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: Fri Nov 22 02:23:47 GMT 2024

Total time taken to generate the page: 0.05534 seconds