Are Object oriented databases still in use?

Question

Quite a while ago, I heard about Object databases. Cool concept and all. Now, with the event of ORMs everywhere, does anyone still use any of the Object oriented Databases s

Answer 1

Object Database is a cool concept up to now. However, implementations are plaqued with Scalability and Stability issues. Now with the right incarnate that addresses these two beasts, the equation may change.

What I thought is, a Data Engine (not necessarily Object Database) and RDBMS can really live side by side, in fact, there is a great place for a Data Engine in the Middle-Tier, Embedded Apps/systems,... Also, a correct implementation of a Data Engine will allow support for both Object Persistence at a low-level and at higher level, RDBMS/SQL constructs. This means your application can choose to work with Objects, use the data engine for Object Persistence AND make the Objects available as Rows/Columns of a table via an RDBMS interface.

This is the ideal setup. We bridge the two technologies and provide alternatives for developers to program in their preferred interface. One may argue we have this now, e.g. - SQL Server has support for hosting CLR Objects, BUT the current implementations suffer from impedance slowdown. i.e. - in the data path is a lot of conversions/translations as Objects != two dimensional data, thus when your App which deals with Objects saves them to DB, the solution has to convert/translate them to row data in a table.

BUT if we reverse the situation, i.e. - the data engine operates on Objects then there will be no impedance mismatch. Adding two dimensional data projections is nothing more than interface implementation of an Objecct Collection, thus there isn't really no mapping/translation that occur when Objects are exposed as data rows of a table. This is my theory.

SO it maybe the next wave of technology on this area is a data engine that will allow Objects as low-level interface and RDBMS interface sitting atop of it. AND this technology is available now!

B-Tree Gold version 4.0 Scalable Object Persistence has this as its main design Goal. It achieves the following characteristics and thus, it is well adapted to being the data engine of choice for the next RDBMS, which basically is a layer on top of it. Two of its main key points are: Scalability: 100 million Inserts in 17 hrs in an ordinary/avg equipped laptop. Stability: industrial strength transaction that will ensure DB is not corrupted and can rollback to a previously committed state.

For this to work, the data engine has to meet scalability and stability required by RDBMS Servers. A very tough task but not impossible. B-Tree Gold version 4.0 SOP has met this requirement, thus, we're really ready to implement this kind of solution, without really shoving it under our neck as SOP gives freedom of choice how you'd like to use it. It can be used in a lot of ways, e.g. - complementing RDBMS Servers as middle-tier caching station, embedded DB in the client side, etc... not to mention being the low-level data engine of the RDBMS server itself!