Hi Wayne,
Thanks so much for the detailed reply. It was exactly what I
was looking for. I started looking more into using ODBMS solutions after
seeing some facts like these http://www.odbmsfacts.com/faq.htm . Ofcourse,
I have to do my own evals based on my requirements, before I embrace this
technology.
<Wayne>
An OODBMS will be faster and simpler as long as your logic is
object-oriented and mainly you query using navigational methods (find this
object's associated object, etc). If you're doing bulk data handling (give
every employee a 10% raise, calculate total sales, etc) then RDBMS is a lot
faster and easier. Certain OODBMS apps can be hundreds (not just tens) of
times faster than RDBMS solutions - depends on how you partition the RDBMS
(you **really** want to avoid nested joins) ... it all comes down to your
app :)
</Wayne>
I'll keep that in mind in doing my evals for bulk data handling. But, I
believe Versant comes pretty close to any rdbms while handling bulk data.
<Wayne>
Vendor lock-in can be harsh with OODBMS - so look for ODMG bindings, and
stay at that level.Use OQL for you complex queries ... but make the queries
loadable somehow, to be easy to change as you change your object schema...
lots of folks embedd the OQL directly into their code and then have a
brittle maintenance problem on their hands. So, use OQL and externalize it
somehow ... a tad slower, but it gets you away from detail representation
issues.
</Wayne>
I agree with you on this. I guess, this is more because the industry
is not following enough open standards in regards to odbms. I guess, that
answers the question on, why there is less integration between 3rd party
tools to an odbms. It all becomes proprietary. Seems like this one issue
itself would be reason enough for me to discard the use of this technology.
Let me see, if things change in the future. I would definitely keep a watch
for this.
<Wayne>
Some tools (such as Versant OODBMS) are handle distibuted cached multi-user;
many won't (they just lock pages of disk memory, for example). The lock
structure can be hard to understand as the vendors tend not to highligh it,
but it's really worthwhile to find out how they lock and compare that to
your object use patterns. For example, if an OODBMS locks at the disk page
level (and some lock at that level and load your client cache as a disk
image) then you may get *super* pre-loading effect and great performance if
you data is small object located close together on disk - as is common in a
CAM application - but causes dramatic slowdown in multi-user scenarios with
small sctatered oject (due to contention on collatorally-locked objects).
</Wayne>
I'm zeroing in on Versant more just because it provides me a highly
fault tolerant system with a with multi-user cache.
Thanks again Wayne for the detailed reply. Btw, I dont think OQL is
any rocket science to figure it out. Any developer could get used to it
easily. In fact, I think the average developer would find it lot more easy
to deal with Objects directly instead of having all those confusing O-R
components.
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".
