Anyone ever tried one, or is this just crazy talk? I've been hearing a little bit about Magma and Gemstone in Smalltalk, and I'm curious if anyone's ever created an OODB I could use with Ruby. Bit of a random question, just wondering.
on 2007-02-16 18:03
on 2007-02-16 18:31
On 2/16/07, Giles B. <firstname.lastname@example.org> wrote: > Anyone ever tried one, or is this just crazy talk? I've been hearing a > little bit about Magma and Gemstone in Smalltalk, and I'm curious if > anyone's ever created an OODB I could use with Ruby. Bit of a random > question, just wondering. IMO, OODBs aren't worth any effort or time. (They're not even worth the time it takes to debunk them, IMO, but there's a lot of stupid people out there who think they're good ideas.) That said, there are some interesting database things (possibly including an OO-access database -- GOOD, I think) at: http://www.garret.ru/~knizhnik/databases.html -austin
on 2007-02-16 19:24
> IMO, OODBs aren't worth any effort or time. (They're not even worth > the time it takes to debunk them, IMO, but there's a lot of stupid > people out there who think they're good ideas.) Well, if anybody is idling around with nothing better to do than debunk object databases, I wouldn't.
on 2007-09-26 01:04
On 2/16/07, Giles B. <email@example.com> wrote: > Anyway, if anybody does have time for some debunking, or indeed some > plain old bunking, that would be nice, and if you can do it without > insulting anyone I've made friends with, well, that would probably be > easier for me personally, in case I wanted a second onion or > something. Fundamentally, OODBs are based around the idea that if OO is good development practice, it must be good data storage practice. This concept is, well, flawed. (That's a charitable description, really.) The problem is that OODBs tend to lock you into a single object model (of your own devising, no less) and the moment you discover that you need an alternate way of querying the data (what do you *mean* you need to be able to summarize all of the sales of this item? I only have my data organized by customer!), you're screwed. The number one thing forgotten by OODB and XMLDB enthusiasts is that the data is king. Not the representation of the data, but the data itself. Relational databases -- such as they are -- get this right. There's no One Right View to data, but there are ways of Relating data. Mix the relations properly, and you can have many different views -- and the objects that can be pulled from them are just as complex. http://qurl.com/lk792 (Joel on Software Forum) shows some of the usual ignorance from OODB proponents, but there are some gems from the people who know better: I read an article a while back that made a good case against OODB's. I can't remember where it came from, but the main point was this: Data outlives paradigms. In other words, with a flat set of data to work with, you can always get it to work with whatever the programming flavor of the day is. But when you stuff that same data into an object-oriented model, you're stuck with that model, even when OOP has been replaced by the next big thing. -"Chris" A year later, another discussion broke out: http://qurl.com/mbqsp Two good points from that discussion: [...] The "impedance mismatch" has been talked about since the early 80's, when OO first started appearing. [..]OODB's tend to fall into the "what is OO" trap; they either try to be tightly coupled to a particular language [...] or they are so generic that they end up competing directly with RDBMS's - and losing, since DB customers are enormously conservative [...] older database veterans know that many OODB's are often just CODASYL [network]... databases with many of the same problems and issues that hierarchical databases have always had. Those who think there is some vast conspiracy to keep "better" OODB's from winning are just silly and don't know their history - DBMS's are the perfect example of how those who don't know history are doomed to repeat it... - x [builds relational databases engines] and: You are making a fundamental mistake that will haunt future developers / enhancers of your system forever. THERE IS NO SUCH THING AS HEIRARCHAL DATA. Heirarchies are a VIEW of data, from a very tight perspective. Change your perspective and the model falls apart. Organise your data according to a properly normalised relational model and you will have the flexiblity to grow and change as future needs might require. -HeWhoMustBeConfused Again, this was raised in 2005: http://qurl.com/w54vq This one has someone who is a little more active about defending OODBs, but still makes a lot of the fundamental mistakes. Finally, it's always instructive to read Fabian Pascal or Chris Date: http://dbdebunk.com/ http://www.inconcept.com/JCM/March2004/Pascal.htm That's about all I have time for. The number one problem from my perspective is data lock; the number two problem is vendor lock. -austin