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

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.

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.

> If query language is what bothers you, imagine some OO SQL... i.e. HQL;)
> Yeah really, check HQL:
> http://www.hibernate.org/hib_docs/v3/reference/en/html/queryhql.html
>
> > 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.

A datawarehouse is essentially static data. 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.

> (BTW your real estate example in hypercubes goes like this:
> pronounce city one dimension and color second dimension and run count.)

That query syntax looke like it could work in a RDB as well, except it need a way to get just the grey houses as I originally asked.

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?

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

Both? meaning Network model and Relational model?

> 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. 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.

LOTUS once ruled the spreadsheet market. Things change. 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.

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.

>
> 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.
> I don't need referential integrity or cascades, since OO model takes
> care of it.

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

> 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:
> http://vrspace.cvs.sourceforge.net/vrspace/vrspace/src/main/org/vrspace/server/Transaction.java?revision=1.2&view=markup
> This isn't production code, in fact I've never even tried it, as I never
> needed it.
> But my point is it gets much more simpler with OOP.
> 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.
>
> Regards...

I'll try to look that up sometime. (just not today). 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.

Have a good day.

   Ed. Received on Mon Jul 10 2006 - 20:26:29 CEST