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: Lucid statement of the MV vs RM position?

Re: Lucid statement of the MV vs RM position?

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Mon, 24 Apr 2006 03:17:18 GMT
Message-ID: <2rX2g.65027$VV4.1232702@ursa-nb00s0.nbnet.nb.ca>


Pickie wrote:

> Maybe I ranged too widely in my post.
>
> RE Pick's usefulness. I think Pick is in fact a very good DBMS
> constructor kit. The 'rare expert skills of a dbms developer' are not
> too much different to having an understanding of the Relational Model.

I disagree. Anyone who can understand highschool-level set theory can use the relational model effectively. Only those writing the dbms need to have the rare expert skills of a dbms developer. Only those analysing the requirements and designing the schema need to have those rare and expert skills. Only those establishing the physical structure to meet the performance requirements of disparate applications need to have those rare and expert skills.

But as I said, anyone who can understand highschool-level set theory can use the relational model.

> Even with the fairly grunty SQL DBMS toolsets there seem to be a lot of
> crap design decisions, so maybe forcing people to learn a few
> disciplines is good?

Forcing casual users to have the expertise of designers and analysts is a disaster. Forcing them to have the expertise of dbms implementers is too stupid for words.

> RE The term 'model'. Maybe if I state that capitalised 'Model', as in
> 'Relational Model', refers to formal mathematical Model; while lower
> case 'model' is a generic, plastic term. Even using the most primitive
> file mechanisms and Fortran or Cobol, surely we are trying to 'model'
> some aspect of the real world.

If by real world you mean a winchester drive with multiple read/write heads on parallel arms, I suppose so. However, we use higher level abstractions to shield casual users from such gobbledeegook.

> RE "See Dijkstra's comments on the illusion of power." Did I make any
> case for a magic elixir? Or did I want to get rid of the programmer?

You don't have to. Pick exhibits exactly the sort of imprecision Dijkstra refers to which is the root of the illusion of power.

> I just don't see the relevance of the reference.

Since you are a pickie, that doesn't surprise me in the least.

> RE Incompetance, wickedness/profit motive, etc. Date & Pascal were
> plugging a TRULY RDBMS a while ago... seems to have died the proverbial
> (Dataphor? Alphapro? something like that). Maybe there's just not
> enough brilliance in the world to do this job (building a relational
> DBMS).
You are an idiot. If I built the perfect dbms tomorrow for $15, I would have to spend billions re-educating the market, and even then, plenty of legacy systems would remain.

Alphora remains in business, and I hope they do so for a very long time indeed.

   I don't see how you can say this is easier than building a
> non-relational DBMS unless you are saying that one cannot build any
> sort of DBMS at all!

Your lack of vision is common among pickies. I am convinced the tool damages your brains. First, one has to contemplate building a dbms. Pick is not one of those. If we look at dbmses that do exist, like oracle or sybase, they have to put in a whole bunch of useless shit to deal with their own lack of logical identity and the horrors of null.

Implementing those dbmses would be a lot easier without all that stupid non-relational shit.

   I do this all the time with my Pick multivalue
> list-oriented database constructor kit!

I doubt, very much, that you have the capability to build a dbms with any kit. Just because you have a file processor and one could conceivably build a dbms around the file processor doesn't mean you have ever succeeded in doing so.

> RE Redundancy in Indexes. Even Codd's paper mentions this. I wasn't
> making a strong case, but I have seen the argument made that a
> relational database is very non-redundant.

Not from me you haven't. I doubt you understood whatever argument you read.

> RE Complexity. I was unclear. I was questioning the requirement that
> any and every query must be carried out in such a way that the database
> appears to be static.

So? Question the requirement. That's not part of the RM. While every dbms must have condern for consistency, that concern is separate from and orthogonal to the RM.

> RE References. I had hoped to avoid "Buy a book by Chris Date" as
> being the answer to my request. From the look of it, there are a few
> of his in this series - would I get the right ones? Surely someone can
> point to an open-source web resource!

Don't sweat the book. You wouldn't understand it in any case. Your mind has been too badly mangled. Received on Sun Apr 23 2006 - 22:17:18 CDT

Original text of this message

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