Oracle FAQ Your Portal to the Oracle Knowledge Grid

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: Pickie <>
Date: 23 Apr 2006 16:57:02 -0700
Message-ID: <>

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

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.

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? I just don't see the relevance of the reference. It's usually the SQL DBA who fears programmers, warns how badly they act around data, and wants to get rid of them.

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). 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! I do this all the time with my Pick multivalue list-oriented database constructor kit!

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. Obviously this is implementation-specific. Actually, the storage structure used in Pick is very compact. Used correctly, it is more compact than you would think from looking at the logical model. Mind you, the phrase "used correctly" can be a real killer sometimes.

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. As I understand it, Oracle uses the undo logs to do this and I can only imagine how complex a task it is. Moreover, apparently there is a possibility that the logs aren't big enough to cope with a query, and I cannot imagine what happens then. It's obvious that some data is highly time sensitive and other data is not very timesensitive at all. Bank transactions would be a good example of the former. It seems to me that timestamping data as and when necessary is a lot simpler than providing this capability everywhere.

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!

Thanks for the comments, Bob. Received on Sun Apr 23 2006 - 18:57:02 CDT

Original text of this message