Douglas Barry, David Caplan, Leon Guzenda, Richard Winter. First up - DBMS market shares. "Other" is 9% - which encapsulates OODBs, XML DBs, etc. Interestingly enough, the dbms market is still growing, even though it's fairly mature. There were 10 commercial RDBMS systems, and 5 OSS ones. 7 commercial OODBs, 6 OSS ones. 20 XML DBs, and 10 OSS ones in that area. There are also a number of specialized products in various niches.

The mainline dbs (Oracle, et. al.) are fighting for the enterprise space - file and data. The ORDB and XML db corps are consolidating. XML and XQuery are growing in popularity. JDO is struggling. Recently, a few OSS ODBMS systems have popped up. Objectivity sees this as a good thing, with these systems doing "missionary" work.

What about the specialized dbms systems? Accelerators, in memory db systems of various types (eg, GemFire). Real time embedded systems (eg, Matisse). Objectivity says: "We can compete against any and all of these".

Next - Douglas on when to consider an OODB: when you have a business need for high performance and/or complex data. Complex data? Looks like a graph. Often lacks unique, natural identification. Often has significant number of many to many relationships (joins in a relational environment). Often requires traversing a graph structure. The big win for an ODBMS - no impedance mismatch. The data is stored in the same way that it's used. You don't have to build a mapping between the way it's used and the way it's stored.

"Data tends to stick where it lands" - but we continue to have use cases popping up that want to use this data in unexpected ways. Now we've got a complex diagram that - boiled down - says that an OODB in the middle can mediate between your applications (especially those with WS* needs) and the legacy data stores.

Next - Richard Winter on db scalability challenges. The big challenges: rapid growth in the sheer size of the data sets being stored. User populations are growing, and queries are becoming more complex. Users expect data to be up to the minute, and they expect to get near instantaneous answers ([ed] - this is a Google effect. Users have learned that search engines give them answers immediately...).

Scalability features:

• partitioning
• direct, natural modelling of data semantics
• parallel operation
• advanced indexing -the basics (btree) were invented 30 years ago, and a "big" db had 100 records. Things are a trifle different now.
• sophisticated access technique
• query planning and optimization
• highly concurrent operation
• provision for application specific solutions

Demand is rising because the sheer volume of potential data is growing - and the availability of "always on" connectivity is growing. For many purposes, the scaling problem is proportional to the size of the largest partition.

Principal: The db engine should "know" the true structure of the data and optimize around that data. Most of the scaling work has been done on the relational dbs like Oracle and DB/2 - but that still doesn't help whhen you force a graph/network strcuture into a set of tables and rows. That removes knowledge of the structure from the db, and "outsources" it to the application(s).

Question - what about a standard API (i.e., OQL) - this from the OMG guy. The ODMG (now defunct) was working on this, and the files from that group have gone back to the OMG. Beyond the current efforts there, just stuff in the JCP (i.e., proprietary). One thought is that JDOQL may be adopted as a "standard".

Question - what is Objectivity doing with regard to JDO and XQuery? They mentioned that JDO is struggling, and XQuery is getting more popular. Objectivity now has XML import/export, and is planning to expose their internal API's via XQuery. It may be that XQuery ends up being a sort of default OQL.

Question - Compare and contrast Sybase IQ with Objectivity/DB. Sybase IQ is an innovative product for Sybase - uses column storage instead of row storage - in a conventional db, all data for a person goes in a table with multiple columns. With this they use data compression and bitmap indexing. Works for tabular data that fits the relational model ([ed] - I need to look this up). The view here - Objectivity works better for complex data that does not necessarily fit the relational model, and when you are going to tie the db and the app more tightly together (i.e., embedding).