Because object databases have been my business for the last fourteen years, I'm always interested in seeing what people have to say about them. I wasn't surprised to see some strong feelings and misconceptions expressed here, because that's something that's been going on for at least the last fourteen years. With all the experience that I have had with this technology, I feel compelled to write a few things.
First, by way of disclosure, my name is Doug Barry. I work as a consultant in the area of strategic database planning and decision-making. Basically, I help companies understand what object database and object-relational mapping products do, determine if the technology is the right choice for the companies, and focus on which product(s) best meet their application needs. I do this by publishing data books that compare object database and object-relational mapping products in what I call "excruciating detail," conducting training sessions, and providing consulting on product selection. I also serve as the Chair of the Object Data Management Group.
I want to add a few facts to this discussion. First of all, it is not correct to lump all object database products into the same category. Those who are deeply familiar with relational database products will tell you the same thing about those products. All products are not the same. So the general negative comments about object database products concerning such things as recompiling for schema changes, ad hoc queries, product stability, ease of use, etc. do not apply equally to all products. Such sweeping generalizations, like most generalizations, are inherently unfair.
Second, an object database is not the answer in all situations, just as a relational database is not the answer in every situation nor is any technology for that matter. An object database can be an excellent choice in situations where a client has a business need for high performance on complex data. The key here is selecting the best object database to fit the application needs. (There is more information on when to use an object database and related topics at one of my web sites, http://www.odbmsfacts.com/articles).
Third, object databases have become part of our everyday life and few people know this. They are in many applications, such as stock trading, airline ticket sales, voice mail systems, cell phones, pagers, and a wide variety of web sites. Most of my clients who use this technology see it as a competitive advantage and part of their proprietary design and do not publicize its use. They market the features of their product or service, not the technology to make it run. This has created a false impression that object database products are not part of the mainstream technology choices; they are.
One of my clients has gone public with the way in which it uses an object database. That client is the Chicago Stock Exchange. If you are interested in seeing an application architecture that uses an object database, go to the CHX Technical Roadmap. Look at the architecture diagram in the upper right hand corner on page 3. This design is not unusual. It is a multi-tier design where the object database is used for a high-performance trading engine in the middle-tier. At the end of the trading day, the data is written to Oracle for various back-office processing that has grown up around the Oracle database over the years.
As I tell my clients, the bottom line in any type of database design (relational or object), is that you need to deeply understand your data and how you use your data. From that understanding, it is possible to match product features to your application needs in order to increase your chance of success. Sometimes, that best chance of success is with an object database product.
Slashdot Mirror
Because object databases have been my business for the last fourteen years, I'm always interested in seeing what people have to say about them. I wasn't surprised to see some strong feelings and misconceptions expressed here, because that's something that's been going on for at least the last fourteen years. With all the experience that I have had with this technology, I feel compelled to write a few things.
First, by way of disclosure, my name is Doug Barry. I work as a consultant in the area of strategic database planning and decision-making. Basically, I help companies understand what object database and object-relational mapping products do, determine if the technology is the right choice for the companies, and focus on which product(s) best meet their application needs. I do this by publishing data books that compare object database and object-relational mapping products in what I call "excruciating detail," conducting training sessions, and providing consulting on product selection. I also serve as the Chair of the Object Data Management Group.
I want to add a few facts to this discussion. First of all, it is not correct to lump all object database products into the same category. Those who are deeply familiar with relational database products will tell you the same thing about those products. All products are not the same. So the general negative comments about object database products concerning such things as recompiling for schema changes, ad hoc queries, product stability, ease of use, etc. do not apply equally to all products. Such sweeping generalizations, like most generalizations, are inherently unfair.
Second, an object database is not the answer in all situations, just as a relational database is not the answer in every situation nor is any technology for that matter. An object database can be an excellent choice in situations where a client has a business need for high performance on complex data. The key here is selecting the best object database to fit the application needs. (There is more information on when to use an object database and related topics at one of my web sites, http://www.odbmsfacts.com/articles).
Third, object databases have become part of our everyday life and few people know this. They are in many applications, such as stock trading, airline ticket sales, voice mail systems, cell phones, pagers, and a wide variety of web sites. Most of my clients who use this technology see it as a competitive advantage and part of their proprietary design and do not publicize its use. They market the features of their product or service, not the technology to make it run. This has created a false impression that object database products are not part of the mainstream technology choices; they are.
One of my clients has gone public with the way in which it uses an object database. That client is the Chicago Stock Exchange. If you are interested in seeing an application architecture that uses an object database, go to the CHX Technical Roadmap. Look at the architecture diagram in the upper right hand corner on page 3. This design is not unusual. It is a multi-tier design where the object database is used for a high-performance trading engine in the middle-tier. At the end of the trading day, the data is written to Oracle for various back-office processing that has grown up around the Oracle database over the years.
As I tell my clients, the bottom line in any type of database design (relational or object), is that you need to deeply understand your data and how you use your data. From that understanding, it is possible to match product features to your application needs in order to increase your chance of success. Sometimes, that best chance of success is with an object database product.