Podcasts: OOPSLA Panel on Objects and Databases
By Ramon Leon - 12 November 2006 under Databases, Programming
Sadly, I wasn't able to make the trip to OOPSLA this year, but I found a few podcasts that covered the Objects and Databases: State of the Union in 2006, as well as a few other interesting ones. It's great to hear these issues being discussed, dealing with databases and objects in still one of the fundamental problems in our industry.
There aren't any easy answers, there are benefits to both object databases, and relational databases. The butchering of an object model so it can be shoehorned into a relational database via some mapping layer isn't the answer. Industry wide, the relational folk seem to think this is a solved problem and object databases are modern dinosaurs. Mathematically, they may be right, pragmatically, they're absolutely wrong, and the academics are wrong as well. I don't care how pretty the relational model is, programming to it is a nightmare and doesn't fit the way programmers actually work.
Databases will learn to deal with objects as objects, without crippling them, or they will be replaced with ones that can, period.
Whatever the future of databases are, they will need to learn to deal with random queries (a weakness of object databases) and fast access to objects with a nearly transparent API (a weakness of relational databases). As Esther Dyson says, "Using tables to store objects is like driving your car home and then disassembling it to put it in the garage. It can be assembled again in the morning, but one eventually asks whether this is the most efficient way to park a car.''
There has to be a better solution!
Comments (automatically disabled after 1 year)
I'm waiting to try the new Gemstone for Seaside. I'm hopeful it'll fulfill my desire for a query-able, scalable, easy to use database. I've tried GOODS and Magma and been disappointed for various reasons with both.
As for your proof of concept, what's your relational schema look like? You probably should put it up on SqueakSource.
Well for sure Gemstone will rock in odb matters and in Smalltalk it has no match. None reaches a half of what it is capable of. It seems to scale in whatever but financially.
But I like the Gemstone experience or the gemstone illusion as I read before. As I have no time to invest on it, I think I'll clean up a little and post it there so people can play with it.
For this system I made the relational schema looks really simple (but not simplistic). Relationally it's trivial. There are 3 tables: 1. The object table which stores one instance per row 2. A table that maps the name of the classes. So you can name a class and know whci id matches in the object table. (Was very fun the Moebious thing that happened with Metaclass class there). 3. A table with one record to tell who is the root of the graph. So schema is very simple and very similar to the instances in RAM. You can store there most of the objects. I think more or less like an image segment. I think context, things with resources, etc cannot be stored. But my initial target was common business objects.
I've made in march of this year it because I like things like Magma which I'm using now but RDBMS's some times are a constraint for a contract and I wanted not to be affected by that. Getting freedom to the way you use the RDBM's at your application level usually is easier.
As this odb rdbms supported creature behaves somehow a shared image segment of the image, makes accidentally that you can use it as a persistent language. A persistent portion of the image. Every change you make to every object is transactional. So the solution space of that may be not that big. But for sure you can heavily load of client images with N connections that RDBMS.
Also it's plenty of space for optimization which I don't made including write and read barriers, caches, transactions not so granular, etc.
Yeah... absolutely agree. Your phrase: "Databases will learn to deal with objects as objects, without crippling them, or they will be replaced with ones that can, period." says it all. The claim is valid the vendors are unable to materialize something acceptable. Maybe they don't want to do a relational database that is also an object database. The actual problem born when we want to map objects to rows and classes to tables. Why we do want to use objects at all when can model reality with data?
Well as I see objects allows us to map, in a virtual environment created by computers, the concepts we naturally form in our heads. Now this conceptual mapping is 1:1 to objects but there is another "tool" to map our concepts in this computers: Mathematics. The boolean model in which computers are based due to the holy transistor "suggested" to chip vendors that programmers need more tools to do mathematics than to do virtualization of concepts. The result? hardware less prepared for a conceptual tool like the object technologies. Oh.. by the way the object model has no problem at all to deal with heavy mathematics so mathematics become a piece of it's paradigm but the conceptual-friendly object paradigm is enormously wider. While in theory the object paradigm can "pass" from relational to object and object to relational, the transform (for instance mapping frameworks) that maps it in the relational elegantly complete paradigm could have a price not allways reasonable for persons (not dedicated to mathematics). But without warning that path leads the persons that program to pay a big price for it's object-relational impedance mismatch. When the complexity grows the price may grow and may grow not linearly. If you feel that then you may have a problem. We feel clear how the conceptual model is sometimes formed in seconds but the impedance is so high that we can be transforming objects to rows and rows to objects days or weeks. At that point ODB's start to be appealing.
Frustrated with that and I've ventured to make a proof of concept that uses RDBMS's in a radically different way. It maps rows to instances but it don't map classes to tables. It maps classes also to rows because classes are objects. Basically the same way Smalltalk maps an instance in RAM that in the end is a kind of fast big table.
It works but is probably too slow for real use because the holy RDBMS's are so slow to do real work. May be I put it in SqueakSource.