Pretty interesting. I never heard of db4o before. I'm skimming the tutorial (http://www.db4o.com/about/productinformation/resources/db4o-...), and it looks fairly nice.

It seems that db4o supports some pretty flexible query mechanisms. That leads me to worry about performance. One of my recurring nightmares of relational databases and SQL is optimizing queries on non-trivial constantly-evolving schemas, and I can't help wondering if db4o has the same horrors in store.

Unfortunately my tests have been too basic to give any advice in your situation. Adding data elements has been nothing more complex than adding it to the class. Queries that filter on elements in a single class are trivially easy - but I think there are types of applications that need nothing more. Querying across classes would require more work than the relational equivalent of querying across multiple tables.

HOWEVER, my sense is that bringing a relational mindset to object databases is not going to realize the full potential of them; you have to think about storing the data elements differently.

Object databases seem great for OLTP apps. In particular, ones that require working with individual accounts/patient charts/etc, i.e. query a person's account, modify a data element, and save it back to the db. For something more analytical, like spotting trends in historical data, I'd prefer the full power of an RDBMS and the SQL language that goes with it.