Some people to convert jdo2.2 to d ?

[Christopher Wright]

Aarti_pl wrote:
> dolive pisze:
>> the ddbi progress is too really slow, difficult to look forward toĄŁ
>> data nucleus is more high-level like Hibernate.
>>
> 
> ...and this high-level design is IMHO mistake. Especially mapping 
> relations from db to objects.
> 
> Well maybe someone will give me examples where domain objects are more 
> useful than relations? From my observations presentation layer (GUI) is 
> also relational, so I don't see a sense with making conversions:
> relation -> object -> relation.
> 
> I am working on db access framework which makes use of relations rather 
> than creating objects. And it makes it in typesafe way...
> 
> BR
> Marcin Kuszczak
> (aarti_pl)

It's fine if you're just doing CRUD operations. At my job, we do staff 
scheduling software -- I'd kill myself if I had to write the scheduling 
engine or rule violation code in terms of database rows. And that would 
be a major performance issue.

A good ORM solution will help prevent data inconsistency issues. Let's 
say you need this superfast query in one area but it returns some data 
that you already have. If you manipulated that data in memory already 
and haven't committed it to the database already (because database 
access is slow, so you don't want to be committing everything all the 
time), your application will be in an inconsistent state.

Also, touching the database is slow. It requires inter-process 
communication; it requires translating data from the database's internal 
format to whichever format it sends over the wire; it requires 
translating from that intermediate format to something the application 
can handle. If you can do your query in memory, that's often going to be 
faster. There are exceptions, such as when your database schema is 
significantly different than your objects (in which case this isn't very 
good object-relational mapping), or when the query returns very few rows 
and you have a huge amount of objects in memory, or when the database is 
indexed on rows and you don't replicate that in your application.

And doing in-memory queries isn't possible unless you have a collection 
of objects that is a guaranteed superset of the desired output.

In general I prefer ORM. At the very least to translate rows into 
objects, and to write basic CRUD queries for me; that keeps my database 
access layer up to date.

Also, it's a lot faster to write code with ORM than it is to write 
custom SQL. I've heard people saying that if you are writing a custom 
database layer in SQL, you're stealing from your employer. This 
presumes, of course, that you're working in a language with a suitable 
ORM library available.