My project uses ODBMS, because it seemed very easy to use: just create an
object and it is already persistent. The idea was, that you do not have to
have a decoupled data access layer that is implemented by developers with
the neccessary RDBMS experience. Instead, each component (and developer even
with basic DMBS knowledge) is able to directly access persistency services.
In the real life, things turned out to be much more complicated. You need to
became familiar with concepts and standards which I believe are specific to
ODMBSs (such as how to handle persistence of objects contained in contained
primary persistent objects). It may depend on your specific needs, but if
you want to have schemata that are really easy to use and really easy to
maintain, you are very likely to end up applying relational patterns. My
guess is that you have to have very specific data access requirements to be
really able to use the object oriented nature of such a product.
I am familiar with only one specific ODBMS. This one does not seem as mature
a product as RDBMSs (worse documentation, missing basic features). It can be
tuned to yield very good performance, but you need to use fairly complicated
product-specific tricks.
The bottom line is that for real life tasks you need to be familiar with the
product as much as in the case of an RDBMS. If you already have extensive
experience with an RDBMS, I do not think it will pay off to switch to an
RDBMS. And your customers are likely to have similar considerations, thus
you may find it more difficult to sell your product, if it uses some ODBMS.
Peter
-----Original Message-----
From: Winston Gnananayagam [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 02, 2001 8:46 PM
To: [EMAIL PROTECTED]
Subject: Offtopic: Experiences with ODBMS...
Hi all,
Can anybody share their experiences in deploying a design solution
that involves an ODBMS. Are there any major pitfalls in using a ODBMS to
persist your objects as opposed to using a relational database. I'm not
trying to completely avoid a relational database, but I need a odbms that
could co-exist with a rdbms and take care of persisting my objects.
I'm right now evaluating some ODBMS products, which will provide
simple means for storage and fast retrieval of my objects in a distributed,
multi-user environment. Support for retrieving data using complex queries is
an absolute necessity.
My goal is to avoid all the middleware components(O-R Tools)
that's needed to keep my objects persistent. Hopefully, I'd also avoid
further bloat of my application without any use of Entity Beans. I'm sure my
application would end up with 40% less code. I've been also hearing that in
certain cases the applications using odbms products are 10 times faster than
the ones using rdbms. Seems like the cost benefits of using an ODBMS product
is extremely good as they are a lot cheaper than the existing RDBMS
products.
Anyway, my bottom line is, I'm looking for a solution to persist
my objects and retrieve them fast. I don't need anything fancy at all that
today's RDBMS products provide. Any pointers/tips/warnings from architects &
developers will help me out a lot.
Winston.
===========================================================================
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".
