<vendor rant>
Larry's use of the word 'break' is probably a little harsh (at least in
public :^) ). In my opinion, the mixture of complex object relationships
with OR Maps results in the following:
* Poor performance. This varies from application to application,
depending on how well the usage pattern of the objects fits the way the map
works. As data sets get larger or models get more complex, the relational
joins become more and more expensive. The map can, and almost always must
be, tweaked to improve performance, but this often requires changes to the
way that the objects themselves are used, inducing the following problem.
Tweaking tends to be application specific, meaning that an improvement for
one usage pattern can be a detriment for another.
* Influence on the Object Model. As an object modeler or application
designer, you must keep in mind how your models or usage thereof will affect
the mapping layer. You will eventually find yourselves adding different
kinds of methods that either retrieve objects 'deeply' or 'shallowly', or
factoring your objects into 'primary key' and 'not primary key' pieces.
This adds to the complexity and reduces the effectiveness and re-usability
of your object model.
* Fragility. As the object model or usage pattern changes, the map
must also be changed. Some of the tweaking will be obsolete, some old
tweaks may cause new inefficiencies. This is a maintenance liability. The
effort alone of keeping a map in synch with a new object model is large.
Fortunately, the default 'untweaked' maps will due in the early prototyping
stages when performance is not critical and the mapping tools can regenerate
the maps quickly.
* Data Integrity Failure. Now, maybe I didn't get it, but I could
never get cascading deletes to work properly in relational databases. I
always ended up turning them off and doing it manually as soon as I had a
second application running against the same data. Different applications
manipulate relationships differently. One application does not (and should
not) know how to properly delete records so as not to affect the other.
Take for example a Sales Order system. It may maintain product catalog. If
a product is no longer offered for sale, it may delete the product from the
system (okay, what about the orders that point to that product?). Add a
manufacturing application to the same system. It tracks bills of material,
that list products. We now have many different references to the same
product record, and no clear way to know when, if ever, it can be deleted.
An object based repository, like GemStone/J, if it has multi-user,
distributed, disk-based garbage collection, can manage this problem
automatically. The product record will remain as long and only as long as
there is a reference to it. This is a big requirement for reusable object
models.
Now, that being said, look again at who I work for. Please consult your
neighborhood, friendly, OR Map salesman for an alternate view point. I only
get paid to remember the bad stuff about OR Maps.
The reality of the market is, however, that there are and will continue to
be relational databases out there, and they have areas of functionality
where they excel. I typically recommend to my customers that they consider
a partitioned architecture, especially in light of the 2 phase commit
capabilities of GemStone/J. Typically large object models can be factored
into two types of objects - those that are proportionally small in quantity
and high in complexity (like the product-bill of material - sales offering -
promotion relationship of the Sales Order system) and those that have
considerably less complexity but make up for it in volume (like the Sales
Order and Order Line Items). This is the kind of division I try to help my
customers recognize in their own applications. Use Object Storage for the
complex objects and relational storage for the high volume, simple records.
No one says that all of your entity beans have to have the same storage
model. For this reason, GemStone has partners that integrate OR mapping
technology. It is not a binary choice of Object vs. Relational - have your
cake and eat it too.
Dave
David Brown
Systems Engineer
GemStone Systems Inc.
2010 Crow Canyon Place
Suite 100
San Ramon, CA 94583
760-510-2754
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
www.gemstone.com <http://www.gemstone.com>
-----Original Message-----
From: Larry Marchman [SMTP:[EMAIL PROTECTED]]
Sent: Tuesday, May 11, 1999 12:14 PM
To: [EMAIL PROTECTED]
Subject: Re: relational storage (was "Re: Granularity of
EJBObjects")
Yes. If an entity bean has an attribute that is not a simple data
type that
is easily mappable(is this even a word?!:-) to a relational data
type(like
Sting and Integer), then the O/R mapping layer could have problems.
Consider
an entity bean with an Employee field. The Employee object in turn
has
complex objects as its member like Address, Company, etc. Breaking
the one
to one mapping between an entity and a table 'could' cause problems
for the
O/R mapping layer of the container. I say 'could' because I am
unclear as to
the current state of O/R mapping technologies. When I was working on
projects where we used O/R mapping(just about all of em), we had to
tweek
things. It certainly was a great thing in that it got us most of the
way
home, but still required additional effort to implement our schemas.
I apologize if my use of the term 'Abstract' to define a complex
data type
confused people. I intended no reference to the modifier 'abstract'.
I heard
someone once use the terminology that way.
Larry
> -----Original Message-----
> From: Sven-Uwe Meyer [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, May 11, 1999 12:00 PM
> To: [EMAIL PROTECTED]
> Subject: Re: relational storage (was "Re: Granularity of
EJBObjects")
>
> Larry Marchman wrote:
>
> > ... Abstract data types in member fields of
> > a bean will not break the underlying persistence as can be the
case in
> other
> > products which rely on mapping to accomplish CMP.
>
> would you mind to explain in some sentences to me, what you mean
are
> where RDBMS (and O/R-mapper) come into trouble ?
>
> thanks, sven
>
> --
>
-----------------------------------------------------------------------
> Sven-Uwe Meyer
> Gruner+Jahr Electronic Media Service GmbH tel. : +49-40-370
377 29
> Am Baumwall 11 fax. : +49-40-370
377 57
> 20459 Hamburg
> Germany email :
[EMAIL PROTECTED]
>
-----------------------------------------------------------------------
>
>
==========================================================================
> =
> To unsubscribe, send email to [EMAIL PROTECTED] and include in
the
> body
> of the message "signoff EJB-INTEREST". For general help, send
email to
> [EMAIL PROTECTED] and include in the body of the message
"help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in
the body
of the message "signoff EJB-INTEREST". For general help, send email
to
[EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
