Re: In an RDBMS, what does "Data" mean?
Date: Fri, 04 Jun 2004 14:58:34 GMT
Message-ID: <u60wc.5736$mK.281_at_newssvr32.news.prodigy.com>
"Anthony W. Youngman" <wol_at_thewolery.demon.co.uk> wrote in message
news:QxXjHkHok7vAFwzH_at_thewolery.demon.co.uk...
> In message <40bd0b99$0$561$e4fe514c_at_news.xs4all.nl>, mAsterdam
> <mAsterdam_at_vrijdag.org> writes
> >Anthony W. Youngman wrote:
> >
> >mAsterdam writes
> >>> This reduces the statement to
> >>> "It was mathematically proven that it is simpler
> >>> than the graph based approaches." and leaves the
> >>> judgement to the reader/student. An improvement,
> >>> but it still leaves the questions unanswered:
> >>> simpler at what? etc.
> >> And Occam's Razor (the Einstein version iirc) says "make things as
> >>simple as possible, BUT NO SIMPLER".
> >
> >The examples given in Alfredo's links did a good job at shaving
> >CODASYL's beard by providing the same and better
> >results (for the "no simpler" part) from a much
> >simpler construct. Did you read them?
>
> Probably. And I probably didn't understand them.
>
> All I'm trying to say is that simplicity as a goal in itself is a
> delusion.
Sorry, but it's not. There are other goals, and sometimes the goals short-circuit one another, but simplicity is always a worthy goal, in every aspect of every design of... well, anything. It's a necessary but not sufficient component of design quality.
> And just because relational may be simpler than codasyl doesn't mean
> that it's a good thing. We have a real-world problem here ... look at
> the following mapping ...
>
> real world <=> business analysis <=> database
>
> What matters is the complexity (or simplicity) of the WHOLE SYSTEM.
And the complexity of the individual components at least form an input to the "complexity measure function" of the whole system.
> There's no point in simplifying the database, if the necessary increase
> in complexity of the business analysis totally negates it.
Agreed.
> By focussing on minimising the complexity of one part of the system, we
make the
> system as a whole more complex.
Not true, at least not necessarily.
> That will explain why Dawn's experience
> is that MV is more productive than relational - the simplicity of the
> relational database over MV simply pushes all the complexity into the
> business analysis side, turning that into a total nightmare.
Oh please. You have to be kidding. Moving from a 3NF-but-not-1NF MV structure to a fully 3NF structure produces, from bliss, a "total nightmare"? That's delusion.
> Which is simpler - to model a single real world entity as a single
> database "table" as MV does (we can model an invoice in a single FILE),
> or as five or six relational tables?
Why do you have attributes? You're, like, totally dissecting the holistic nature of the invoice, dude. C'mon, let's harmonize with the cosmic gestalt and just have one big file with attributes INVOICE1, INVOICE2, INVOICE3, etc...
> And don't forget - our FILE (should
> be) normalised, so we can access it just as if it were five or six
> relational tables ...
>
> Yep. The database itself is more complex. But the business analysis is
> MUCH simpler, such that the total system complexity is a lot less.
In what way does storing the invoice in a single file mean the business analysis is simpler? You still had to identify attributes, and then of course make sure the ordering of elements in the MV attributes is the same, and possibly dissect values into sub-values...
- erk