November 15, 2006
Objects and Databases: State of the Union 2006William Cook, Moderator: We're really starting to get two different viewpoints here, the sort of object relational where the data is owned by someone else and maps it versus the object database, that's the right presentation and everything is just seamless and you don't have to do a lot, but it's all handled in the sort of object style. Here are some questions related to that:
"Tell me a compelling example that illustrates the advantages of an object-oriented database over a relational database?" Just give a specific example and, if you an object relational mapping person, you can explain that why there isn't a compelling reason for that.
Robert Greene, Versant: There are 70,000 servers versus 150,000. So that's just one example and I'm sure that Christof can give another example.
Patrick Linskey, BEA: As an OR mapping person I think a thing that a lot of object databases tend to to better than the relational databases right now is data federation, is having partioning data over a large number of servers. A formerly compelling example for this in America was the telephone exchanged systems where you knew that if you had a 202 number, that went to the DC exchange and if you had a 415 number that went to the San Francisco exchange etc. So data models that are inherently partionable and that's changing because we can port our numbers now and everybody has cellphones. So those types of systems are things where relational databases tend not to scale past a single machine and DB2 or IBM and Oracle were working hard on this problem. This is a problem people are trying to solve. I should point out, that it has little to do with the underlying model but a lot of times when we look at things that are better or worse than one model it's not actually because of the inherent academic properties of the model but often it is because of different implementation strategies and assumptions that the companies developing the products have ended up developing in to their software products.
Christof Wittig, db4objects: I want to stick to this specifically so I just give an example. A consumer appliance which is shipped in the 10,000s and margins are razor-thin, so every single CPU circuit really counts. Most of our developers really look in either writing their own persistence solution or using serialization or flat file. Think of an object database as seamless as serialization but it doesn't break -- it's as seamless. And that's when they choose db4o, so it's much more robust. And as a result, their customer service director said: "The number of service calls has gone down 10% since we use db4o instead of object serialization.
Derek Henninger, Progress Software: So a couple of examples from ObjectStore, in their case it's a very complex indexing structure that the relational equivalent was something like a 20-table join. You can do that kind of thing in an object database you have a lot more control over the sophistication of the structures that you're going to build, you're not limited to rows and columns. Another example would be GIS information which is really much better suited for an object database because it has a kind of navigational feel to it. You need that kind of navigational approach to things in many applications and object databases are far superior for that, you aren't doing the database foreign joins key lookups in order to get the information. Although it's a power of a relational database it's not something that's done efficiently.
Bob Walker, Gemstone Systems: I'm sure that all of us have concrete examples of where a traversing or persistence model by reference rather than accessing by query outshines a relational database. We have one at Gemstone that I can talk about, I can't talk about their name, but a large telecommunication company does all their DSL provisioning with their objects stored and code running on Gemstone VMs. They found that they couldn't do this with the off the shelf product in its traditional accessing of DB2. They simply wrote to the Java APIs and started storing that complex DSL network data in our database. They can provision a DSL switch in minutes or less. It's one of their key successes where the competition in the industry is a day, two day, 12 hours if you're lucky. I think there are a lot of examples where on a certain level of complexity the object databases really start to outshine of relational databases.
I have to say that I'm not opposed to OR mapping. I also completely agree that there's a lot of relational data out there that needs to be dealt with. What I'm trying to look at is "Where are we going next? What are we going to do with all this stuff? How are we going to access in a more homogeneous fashion throughout in the enterprise?".
Patrick Linskey, BEA I think there are relatively small numbers of applications where one particular data model is superior to another. I've seen more examples of situations where an application runs faster for this section and so of that section, always is fast enough or always has enough features or whatever. More often or not the appropriate running data storage solution is probably going to be good enough for the vast majority of any needs regardless of which different kind or varying technology it is. It's really only in the kind of corner cases that a given type of storage pattern makes the difference for the application in the here and now.
Craig Russell, Sun Microsystems: Just one more comment to emphasize that a lot of database people think in terms of third, fourth and fifth normal forms where there's exactly one copy of each piece of data. It's been my experience that the successful applications deal with multiple copies in various stages of completeness and coherence. In order to get an application that works really well you need to be very aware of the transient nature of this data getting more ossified the further back into the system it gets until you finally actually do why that glues on the internet. Once you've made the purchase it should be firm. You shouldn't have any ambiguity or any question.
Robert Greene, Versant: I just want to comment to make sure that the audience realizes, that at last from my perspective, query versus navigational access, which is often sort of focal point of discussions when it comes to object versus relational databases. It's one of the things that certainly I learned in working over 10 years with an object database company, that those are complementary things that you cannot..a wholistic, pure, navigational based approachit may work for something like db4o in the embedded space but it doesn't work in a large scale enterprise application. You have got to have complementary technology from that perspective. You need to go out and query the 80 million instances and bring back some set of objects which are the starting point for your use cases with which you then use navigation to drill down into and exercise your business logic in your model. But you've really got to have both of those things and object databases have evolved substantially in that area of query as a compliment to the navigational capabilities. 
Previous Page |
1 Introduction
|
2 Bob Walker, Gemstone Systems
|
3 Derek Henninger, Progress Software
|
4 Robert Greene, Versant
|
5 Erik Meijer, Microsoft
|
6 Christof Wittig, db4objects
|
7 Patrick Linskey, BEA
|
8 Craig Russell, Sun Microsystems
|
9 Ten Years from Now?
|
10 Data -- It's Scary
|
11 Acronym Soup
|
12 Business and Social Issues
|
13 Back to the Social Question
|
14 Different Viewpoints
|
15 A Bigger Picture Question?
|
16 A Service-Oriented Impedance Mismatch?
|
17 Wrap Up
Next Page
|
 |
|
|||||||||||||||||||||||||||||
|
|
|
