November 15, 2006
Objects and Databases: State of the Union 2006William Cook, Moderator: I want to come back to the social question.
Bob Walker, Gemstone Systems: Sure. Basically it's a matter of being able to take risk or being risk averse. It's like the old axiom nobody ever got hired or fired for using Big Blue. Nobody ever got fired for using Oracle or DB2. I think that there are definite social issues and they have to do with risk aversion. Sometimes it's a hard sell to get people even look at what available object transparency might look like to them.
William Cook, Moderator: Here's an interesting question: "What about the agility mismatch?", "Current tools allow me to easily refactor my class structure but not my schema".
Christof Wittig, db4objects: Exactly! That ought to be addressed and that's why db4objects for instance supports an automatic schema evolution. You can basically just adapt it and you're in charge. There's no dual schema setup. This is the silver bullet not for every application but for many it is. And if people fight back and said "Object databases are all crap", no it's not. It's a matter of context. And those people who disclam that or try to tell you "Object databases are no used"-- yes, they are there. They are mainstream, they are freely available under the GPL, and they work. Try them and you find that it's so much easier, you can go home at five. [Laughter]
Robert Greene, Versant: One of the applications that is running on Versant, I thought that I was going to stay away from this, but it's a Wargames 2000 so it's a global battle management simulation that has been running for a long time. Every single run that they do involves the schema in some form. And they must allow all the clients to work with the data as well as new clients. And so those capabilities were built into objects databases, some of them better than others. But those are important things that we all need to look at moving forward in solving how we deal with data in the language and the way we use languages.
Erik Meijer, Microsoft: I think data should not evolve. You want to present it differently but I don't want certainly all my MP3s on my hard disk to change and now half of the applications don't understand the new format. So I really think it's a bad idea if it's easy to change your data. I don't buy your argument at all, sorry.
Patrick Linskey, BEA: I would disagree with that. I would say that models should stabilize over time. As they do so solidifies the data that they represent. But to say that you'll get the model right the first time: it just rarely happens.
Bob Walker, Gemstone Systems: Some business requirements change, new forms of businesses are created. In insurance there are new rules let's say, in other mathematical forms, there are new computations, data is going to change -- the structure of the data is going to change. I can see an MP3, I might want to have the format the same but if you're writing a new insurance policy or you're creating some new stock portfolio you may have different characteristics of your data than what you originally had.
Craig Russell, Sun Microsystems: Data is going to change -- I guarantee it. And so is the schema, and so is the government regulations, and so are the opportunities that some company has to add a little bit of information and gain a slight competitive advantage. This like Darwin at work here. So data will change. And if you think your schema and data won't change you're literally going to be living in the past -- don't make that mistake.
Patrick Linskey, BEA: I think the Ruby on Rails guys have done some really interesting work with their schema in data evolution strategy, essentially modelling after the kind of a combination letting you continue to use the underlying capabilities in data store rather then putting a new semantic on top of that. And also using a kind of a style mechanism, of protocols, of little scripts to upgrade and downgrade between different versions. That's a compelling way to allow developers to mutate their schema and model over time.
One of the really pesky things that it gets around is: essentially you need to have some declarative mechanism of doing this and you can't do this in a Java programming language or in a strongly typed programming language very easily. There's this weird thing: If you change your schema in an incompatible way, which classes are you executing when you make thatchange? The moment of the change happens both different sets of classes must be understood, it must be available. It's an interesting challenge, I think the Ruby on Rails guys have done it -- at least from a relational standpoint -- in the most pragmatic way I've seen yet.
Craig Russell, Sun Microsystems: I think dynamic languages are a way out of that and in fact that goes for us to say: As much as I love Java, static typing and fixed typing is way overrated in this universe. I'd pose it as a challenge to the audience to say "Why isn't change part of your model? You know it's going to happen -- build it into your model!"
Bob Walker, Gemstone Systems: We've had really hard experience between both Smalltalk and Java, a dynamic language and a static strongly type language in the realms of schema migration for object schemas. And you're absolutely right. Doing it in Java is really difficult.
Smalltalk lends itself so incredibly well to that kind of dynamic schema modification and multiple class versions. It has been our experience that Smalltalk is a wonderful language for this sort of thing and Java is pretty tough. I agree with you, I underscore that, dynamic languages are really something worth considering.
Erik Meijer, Microsoft: So maybe here my Haskell background can show through. I'm not against changing the schema or the model of the data, but the data itself should be read-only and you should not modify your data, so it's very well possible. There might be other people looking at the data so you should not modify it -- destructive update is really bad. That has nothing to do with dynamic typing or static typing or evolution or anything. I just want to make sure that, before you say I'm a dinosaurI'm the one that's declarative here. 
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
|
 |
|
|||||||||||||||||||||||||||||
|
|
|
