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 2/16/07, Giles B. [email protected] 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:
-austin
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 2/16/07, Giles B. [email protected] 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