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 #184483 is a reply to message #184463] Fri, 03 January 2014 02:10 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 1/2/2014 6:36 AM, Silvio wrote:
> On 01/02/2014 04:19 AM, Arne Vajhøj wrote:
>> On 12/30/2013 8:38 AM, Silvio wrote:
>>> 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.
>
> 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.

It has either been a horrible ORM or some horrible "experts".

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

Ah.

ORM's are often good for transactional data (OLTP).

Not as obvious a choice for analytical data (DWH).

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 03:34:06 GMT 2024

Total time taken to generate the page: 0.04932 seconds