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.
