"When to use an Embedded ODBMS," by Rick Grehan, explains in simple words when you would be interested in looking at an ODBMS, and what such a choice gives you.

When should an application use an embedded object database? Or, more precisely, when should a developer consider an embedded object database as an alternative to the more popular (and, probably, more familiar) relational database? This question is really two questions combined. The first is: when is it appropriate to use an ODBMS? The second is: assuming that you have determined to use an ODBMS, when is it appropriate to use an embedded one? (Many of the ODBMS systems mentioned above are available in both client/server and embedded forms.) In this article, I will deal with the individual, component questions separately. The combined answers will be the reply to the original question.

What I want to know is the performance comparison of ODBMS and RDBMS.

What I want to know is the performance comparison of ODBMS and RDBMS.

It depends on what you're doing! That said, there IS the Pole Position benchmark.

What I'd like to know is how do you do BI on an ODBMS. Is there an ETL procedure to follow? Has anyone had any experience doing it?

What I'd like to know is how do you do BI on an ODBMS. Is there an ETL procedure to follow? Has anyone had any experience doing it?

For web sites I know, BI is not done on the production database, but on another one dedicated to BI. So, I can imagine that second database to be a RBDMS offering a better match with BI tools. But the ETL procedure question remains about the first database being ODBMS...

there are some products like db4o that have tools to do replication into a relational database where you would then mine and harvest the data for BI. I don't think you would want to do that w an ODBMS for anything heavy for obvious reasons.

Of course, the problem is that as soon as you're bound via BI or whatever to replicate to a normal RDBMS, you have effectively just constrained at least some aspect of your ODBMS to the limitations imposed by an RDBMS. A RDBMS is more rigid than an ODBMS, and if you intend to EASILY move data from the ODBMS to the RDBMS, then that rigidity will be imposed on your ODBMS schema. Otherwise your ETL logic is going to become very complicated. Ideally, this is a subset of your data, thus making the ODBMS structure a good choice. Otherwise its seems kind of moot.

What I'd like to know is how do you do BI on an ODBMS. Is there an ETL procedure to follow? Has anyone had any experience doing it?

Use SOA and/or ESB/Messaging. Not being able to do ETL against a ODBMS would be a positive thing.

Hi, I think, embedded DBMS is useful if one has to show some sample program and entire setup is in USB drive. Thanks, Guddu http://freesourceutilityhelp.googlepages.com

Object databases have come a long way and in my next projects I wouldn't consider a RDBMS unless it is really necessary. I would hightly recommend at least at the prototype stage to start with an object database, this way you won't spend 50% of your time writing SQL code/hibernate configuration and getting your environment to work correctly. Evolving an ODBMS can be done automatically with existing refactoring tools so changing the data model is piece of cake. Also querying can be much cleaner than SQL (the query model of db4o is brilliant).

Data is more important than objects. The data stored in ODBMS is very difficult to access. There are no production quality tools around the ODBMS. You need to be a programmer to do anything with the data. They keep saying impedance mismatch, but ask a business man who is funding the project. He would rather pay extra rupees to get the program optimized and a whole bunch of SQL written than worrying about usability of her data. If ODBMS can provide pseudo-realtime synchronization mechanism with a RDBMS backend, I see some hope for them to be used in mainstream. Otherwise, they will continue to where they are. Unfortunately, with no great funding going into their development and RDBMS guys are financially just too strong.

There are no production quality tools around the ODBMS.

I think any ODBMS vendor would disagree with your statement, which incidentally comes with no evidence. All serious ODBMS that I know have tools for accessing data, and they certainly are "production quality"

Hey Joseph, Thanks for the interesting article. It sure gave me definitive hints in my quest for efficient data management systems. I'm currently working on a caching solution for our product which should let me store the POJO objects directly and also provide efficient searching capabilities. I looked at numerous caching frameworks available in java, like ecache, jcs etc, but they only gave me half the solution. They're awesome in storing and managing the POJO objects, but they don't provide much functionality for search. I also looked at the search server SOLR from apache, which looked promising at the beginning but eventually i realized that in-order to make it work, there's so much of XML configuration required that I might end up representing the entire RDBMS schema in terms of apache configuration to make things work. After doing all this research , I realized that the only way to manage searchable data together is a 'Database'. This was the first time I was introduced to ODBMS. I was quite impressed with its ability to store and search objects with simple intuitive queries on the top of objects. I think, expressing our search criteria with objects makes more sense than translating our criteria to a adhoc dynamically generated SQL and manually converting the results to my domain objects. The question I had is that.. Whether my conclusions about the search servers or the caching frameworks correct ? Can a ODBMS play a good role as a caching server for searchable data ? I get to hear frequently that the update operation on ODBMS is very expensive.. is it true ? or is it a Myth ?

Could you give me some advantige for using ODBMS instead of ORDBMS 

ODBMS (db4o for exemple) and ORDBMS (oracle 10g)