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

Josip Almasi wrote:
> 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_.

And a Network Model can fit some application purposes. The cases I've seen are where the queries against the data are relatively static (i.e. few if any adhoc queries). Then the network model can out perform relational basically because the indices are built into the entities. But Relational far out performs Network when you go "off track".

So there can be applications for both models. there's just more applications that fit the Relational Model, IMHO. (And judging from the sales of Relational vs Network based DBMS products, I'd say a lot of people agree with me.)

>
> > 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 that is the point, you only ever just load data. It doesn't change. The sales invoices are not open work orders where the customer is changing the line items. Once the sale is complete then you send all the final details to the DW and it's done. It's 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.
>
> Right, IRL we mix models and metodologies to achieve better results.

The different normal forms ARE NOT different data models. There are benefits and costs to going more or less normalized. At least the NFs guide the choices. What design guidelines exist for Network Model? How about for Object Oriented Model?

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

Well thanks for agreeing that the subject is false. Relational is not dead, now or even long term

>
> > 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;)

Flexibility and solid foundation are not mutually exclusive. Large skyscrapers designed to sway in the wind, are built on bedrock foundations. Good software is built in analogous ways. The most flexible databases I've seen were designed for it. And just think about Relational DBMS. The DBMS itself is built using the Relational model.

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

Yes. Note that I never said Relational was necessarily better for OOP. Or Neural network programming.

>
> But relational model itself isn't enough for a real world app. That's
> why we have cursors after all.

Huh? that doesn't make sense.

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

Bill of materials is the classic Hierarchical Model example and supercession is the classic network model example. Both have been implemented in Relation model databases. Dealing with supercession data is a pain even in network model DBs.

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

Your sense of smell may be off.

Network models can be better for data used in some applications that doesn't suit the relational model. But there are other applications whose data doesn't suit the network model. In fact I would conjecture that there is not set of application data that can be represented in one model that cannot also be represented in the other. It comes down to a question of flexibility and performance. And in general Relational Model implimentations win that battle.
>
> > Then you are storing a flat file model in in a RDBMS product, but you
> > are not using the Relational Model.
>
> Exactly.

So then why not use a flat file. You are gaining very little by forcing a poor design into a DBMS (relational or other).
>
> > 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).

Huh? again. Triggers respond to events, so how is some other event model going to be faster than triggers. I just really don't understand this point.

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

I think you are referring to a different application of aggregates than I am. I've not done Neural net programming, so I missed this point. If there are other example applications, how about listing two or three? Or do you refer to just the BOM and supercession examples?

And judging from your comments bout NN being all about aggregates, you seem to imply the aggregate values need to be stored rather than generated "on the fly". Or I am misreading the context of your comment.

> ... well I ended using RDBMS as record manager:))
>
> Regards...

Well if you only need a record manager, just use a record manager, and forget about a DBMS of any kind.

The relational model is not going away. We need a wide set of tools to attack problems. So if a network model DB is best to solve your application problems, then use it. If a flat file is best, use it. Or if a relational Model DB is best use it! just because a flathead screwdriver is more general than a phillips head screwdriver doesn't mean you throw away your phillips head screwdriver. Use the right tool for the job.

I'm learning some new things in this thread. So thanks all.

   Ed Received on Wed Jul 19 2006 - 21:23:55 CEST