Re: I think that relational DBs are dead. See link to my article inside

From: Bob Badour <>
Date: Mon, 10 Jul 2006 13:35:44 GMT
Message-ID: <QIssg.8644$>

Josip Almasi wrote:

> Ed Prochak wrote:

>> Consider a simple query. let's say the database is for real estate. You
>> have objects for cities and homes. How about counting how many homes
>> colored grey in each city?

> But what do you think how RDBMS does the trick?
> It uses hierarchies (indexes) to fetch the data, then performs
> intersection (on indexes if possible), then count.
> OODB should do the same or alike.
> If query language is what bothers you, imagine some OO SQL... i.e. HQL;)
> Yeah really, check HQL:
>> But Dmitry is claiming network Model. At least he hasn't objected to my
>> calling his DB that and he has used the term himself.

> Sure, these are my notes based on my OR mapping experience. I believe we
> get much alike stiuation in... well, ON mapping:)
> One can view such a network as separate trees: inheritance tree, member
> tree, package tree... these trees do overlap and form a network;
> however, pathfinding isn't general directed graph, it's tree.
>> but I note you build upon a RDBMS. leading me to think you agree that
>> the premise of this thread is false, even in the long term.

> Well then, let me elaborate:)
> RDBMS are good for OLTP, as they maintain referential integrity etc.
> But normalization screws reporting.
> So we got data warehousing DBMS that have nothing to do with relational
> model, don't have transactions, don't bother with integrity etc etc, all
> to get reporting better.
> (BTW your real estate example in hypercubes goes like this:
> pronounce city one dimension and color second dimension and run count.)
> As for the purpose of application state persistence, they both suck, and
> OODB will rock.

Le plus ca change... I heard idiots making identical claims in 1991. At the time, the statements exposed profound ignorance, and they still do.

> For OO apps that is. Most apps in OO languages are built on top of ER
> model, cuz kids learn that in school:)
> Now, I cannot honestly say that RDBMS are dead, as long as two of the
> richest men on earth make their money from them, and push their money
> into them.

But one can honestly say that OODBMS are dead. I said as much more than 10 years ago, and I have seen no evidence that anything has changed in spite of an intervening standards effort, the tireless efforts of scores of self-aggrandizing ignorants etc.

It's not much of a technical reason as you see;) But one
> can't make OODB that would work in clusters without some serious $$$.
> So for the time being, RDBMS will remain along.

I can only conclude you lack intelligence, education or both. The reason RDBMS will remain for a long time is exactly the reason why OODBMS is going nowhere: the foundations upon which each is built. One is founded on modern mathematics and the other is founded on nothing much in particular.

> WRT technical reasons... OK I'll give you an example.
> I do use RDBMS for storage but the way I use it I could use dBase too.

Why do you do that? Are you braindead or something?

> I don't need referential integrity or cascades, since OO model takes
> care of it.

Yeah, sure. Right.

> As for transactions logs, checkpoints, rollback, rollforward, isolation
> levels and other RDBMS buzzwords, it took me 5 hours to write these in
> 125 lines of code:

[rolls eyes]

> This isn't production code, in fact I've never even tried it, as I never
> needed it.

I see. You won't need it until you need it. And then what?

> But my point is it gets much more simpler with OOP.

Correction: Your ignorant assertion is it gets much more simpler with OOP. Any informed and reasonably intelligent person will think you are a nut just for saying it.

> And it's not about object model vs relational model; it's _event_
> model(s) that we get with OO languages that make things easier.

Is it? And what is the foundation of these event models you imagine? How do they differ from triggered procedures? Received on Mon Jul 10 2006 - 15:35:44 CEST

Original text of this message