Re: I think that relational DBs are dead. See link to my article inside
Date: Thu, 20 Jul 2006 19:17:53 +0200
Message-ID: <e9odrg$lb0$1_at_ss408.t-com.hr>
Ed Prochak wrote:
>
> 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.)
Well that's an argument I can't argue against...:) Unless we see filesystems as databases (DEF database: organized collection of data) and operating systems as database management systems (DEF DBMS: program(s) designed to manage database). Basically hierarchical, but symlinks turn filesystems into networks. Just, 100% market penetration, and we take it for granted:)
> 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.
OK then.
>>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?
But there's a number of design patterns... http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29
> Well thanks for agreeing that the subject is false. Relational is not
> dead, now or even long term
NP I'll agree again if it means so much to you;)
> 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.
I have do disagree on this one. The ultimate reason - each model is incomplete. And I can pull that to architecture too - cathedrals are not built on any model and no model explains how they work.
> Yes. Note that I never said Relational was necessarily better for OOP.
> Or Neural network programming.
Oh I noted a while ago you're not fundamentalist:) Neither am I, I'm just a practical guy.
>>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.
Well then maybe I'm simply used to traverse trees so I feel no pain when I do it:) Unless I do it in rdbms that is.
>>Smells like networks are more general however. Each time we draw an ER >>diagram we prove it;)
>
> Your sense of smell may be off.
LOL:))
In fact you're right, literally:)))
As a kid I fell on my nose and...:))))
> 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.
I'm not sure I understand this right. But in the meantime David and Dmitry explained how one model can map the other so we can conclude this.
> It comes down
> to a question of flexibility and performance. And in general Relational
> Model implimentations win that battle.
Sure. But as I stated earlier, IMHO it's not up to model, it's due to vast resources that have been spent on RDBMS research and development.
>>>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).
Oh but I do use files:)
I simply noted that 'vrspace with mysql' was most popular topic on our
forums, and said 'heck customer is always right';)
I really gain nothing. But if I tell them they gain nothing they'll just
call me idiot and go elsewhere:)))
>>>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.
It's faster since RDBMS adds overhead like transaction logging. When you do it in memory you get simple addition and nothing else. This is too simplified of course but the difference is measured in orders of magnitude.
>>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?
Oh, no I really do have long and fruitfull programming practice:))
Though there's not much code I can show.
Good example of what I'm talking about is NeuroGrid,
http://www.neurogrid.net/
This impl is built on top of RDBMS. My alternative implementation uses
in-memory event model and is faster... uh I forgot but two orders of
magnitude.
My impl is in vrspace project cvs, but it's not integrated. I used it in
another proprietary project. Anyway, it's org.vrspace.neurogrid package,
http://sf.net/projects/vrspace
http://www.vrspace.org/
VRSpace itself is mix of N-dimensional address space and network DB on
top of either FS or RDBMS.
> 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.
Quite the opposite, aggregates need to be generated on the fly.
I.e. one neuron has up to 10000 synapses, and 'triggers' depending on
their values. The actual function implemented by this neuron may differ
significantly.
And, neuron and/or synapse states need to be persisted, otherwise NN
just dies when you shut it down.
> 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.
Agreed completelly.
Regards... Received on Thu Jul 20 2006 - 19:17:53 CEST