[linux-elitists] (from Pigdog) Feuerstein on Oracle

Mr.Bad mr.bad@pigdog.org
Sun Oct 22 16:55:25 PDT 2000

>>>>> "JS" == Justin Sher <justin@squinky.org> writes:

    JS> You want to know why OODBMS aren't going to catch on?
    JS> They are SLOW

Same thing was said about RDBMSs back in the 70s, man. OOP languages,
too, up until the 90s.

Performance comes from optimization comes from people who use
something wanting it to be better. There's nothing intrinsic in the
OODBMS concept that makes its implementations into poor performers.

    JS> and they encourage data denormalization

How's that, again? First, do the rules of data normalization make any
sense in an OODBMS world? Second, why would the concept of an OODBMS
violate the fundamental precepts of normalizing data (keep everything
belonging to a "thing" together)? Seems like nicely-designed,
well-encapsulated objects are the best way to keep data "normalized."

    JS> which is why chumpy non-database people like it because they
    JS> don't get the "Tao of the subquery", if you know what I mean.

OK, lemme get this straight: I'm saying that OODBMSs should be better
to get rid of the object-relational impedance mismatch. YOU are saying
that that impedance mismatch is fine, but people just have to learn to
use crap-ass hacks like subqueries. Am I following you correctly? How
can that possibly make any sense?

    JS> That, and when people try to represent objects as relational
    JS> views database optimizers get very confused and the
    JS> performance goes down the drain.

Having WHAT to do with OODBMSs? I want nothing to do with
object-relational -- it's a SICK thing. I want it gone, and of the two
models the relation is the crappier one. So, it must die.

~Mr. Bad

 /\____/\   Mr. Bad <mr.bad@pigdog.org>
 \      /   Pigdog Journal | http://pigdog.org/ | *Stay*Real*Bad*
 |  (X \x)   
 (    ((**) "If it's not bad, don't do it.
  \  <vvv>   If it's not crazy, don't say it."

More information about the linux-elitists mailing list