Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: I think that relational DBs are dead. See link to my article inside

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

From: Josip Almasi <joe_at_vrspace.org>
Date: Tue, 18 Jul 2006 14:09:42 +0200
Message-ID: <e9ij1t$r15$1@ss408.t-com.hr>


Ed Prochak wrote:
>
> Either OODB does something different and possibly better, than RDB,
> Or OODB does the same as RDB and thus logically not better.
>
> You cannot have it both better and the same.

Right.
My point is, I can have it better _for the purpose_.

> A datawarehouse is essentially static data.

Well, not exactly true. While you can't add dimensions (iow change structure) just like that, you can feed it in (near) real time. So it's as static as rdbms:)

> But building a DW does not
> mean throwing out referential integrity, constraints, and other
> features. Normalization does not necessarily scrrew reporting
> performance. (at least performance is why most people denormalize
> tables, the same report comes out either way).
>
> And even denormalized, it is still a Relational model DB, whether it is
> first normal form, or fifth normal form. Many production RBD instances
> are mixtures of normalization levels.

Right, IRL we mix models and metodologies to achieve better results.

> Internally how does the OODB process that? Are all house objects
> somehow grouped together so it doesn't have to search every object of
> the DB to find them?

Well I don't know of OODB internal workings. Though I guess attributes need to be grouped, yes - indexed as Dmitry said.

>>As for the purpose of application state persistence, they both suck, and
>>OODB will rock.

>
> Both? meaning Network model and Relational model?

No, I ment relational and multidimensional model. While first is better for oltp and second for olap, I expect network model to be best for persistence (of OO apps).

> Dmitry's arguement at least initially was:
> I built this great test database using the network model,
> It solves my neural network problems much faster than a relational DB
> therefore, Relational Model is dead (see subject of thread).
>
> My point has long been that his argument is flawed.

Well, right, at least the way you put it. I agree this one argument is not nearly enough so I started giving some of my own;)
But of course, 'are dead' is (intentionally?;)) overstated.

> Now regarding your arguement for OODB model: we are missing someone
> like Codd to define the fundamental principles of the Object Model and
> demonstrate the advantages over the Relational Model.
>
> When that someone shows up let me know. (I like learning new things.)
>
> meanwhile I'll stick with Codd.

Suit yourself:)

I don't really think there's some big strictly defined mathematical construct named 'object model', and I don't even think there's a need for such a thing, in fact such a construct will only limit OOP, only to make us find something more flexible;)
After all, these objects are nothing more than structures containing pointers to data and pointers to functions. Instancing and other OOP buzzwords only makes things easier.
If you look at it as data model, it's network. Therefore, whatever naturally describes as network fits better to object model; whatever naturally describes as sets, fits better to relational model.

But relational model itself isn't enough for a real world app. That's why we have cursors after all.
Most common example are substitutes; we have them from restaurants to electronic stores:
BC108C is substitute for BC108B while BC180A is substitute for BC108C etc etc, so we have self-referring entity. How does sql query for 'show all substitutes for BC108B' look like?

Smells like networks are more general however. Each time we draw an ER diagram we prove it;)

> Then you are storing a flat file model in in a RDBMS product, but you
> are not using the Relational Model.

Exactly.

> I've done enough embedded programming to agree that event driven
> programming makes many things easier. I'm just unsure how it would
> apply to database design.

In a sense it makes select sum(*) and count(*) etc obsolete - makes aggregate generation easier (and much faster than triggers). Aggregates don't need integrity - you can generate them on the fly whenever, provided you store events as they come. NN apps are all about aggregates. And they're not the only ones... ... well I ended using RDBMS as record manager:))

Regards... Received on Tue Jul 18 2006 - 07:09:42 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US