Re: Relational and multivalue databases

"Eric Kaun" <ekaun_at_yahoo.com> wrote in message news:YBzYb.23125$Ir2.20735_at_newssvr16.news.prodigy.com...
> This letter (monograph?) is in reply to Dawn Wolthius, who received what
> she seems to have considered a short and unhelpful series of responses
> from Fabian Pascal between October 9 and November 12, 2002. This was
> also motivated by postings on the comp.databases.theory newsgroup,
> specifically the “foundations of relational theory?” thread which began
> on September 26, 2003 and accumulated over 500 responses before petering
> out on November 7, 2003. The length of my response to all this indicates
> the depth of my fascination with the entire discussion.
>
> For those who would flame me for opening old wounds and awakening
> sleeping dogs, I apologize, but I believe this discussion still has
> merit. I can appreciate Fabian Pascal's apparent crankiness, given that
> he's been answering the same questions and debating the same issues for
> over 20 years now. I do see reason to resurrect this debate (pedagogy),
> but it needn't be the same people who do it generation after generation.

Good luck. I predict you will discover an inexhaustible supply of vociferous ignorami.

> And kudos to Dawn for always being willing to ask questions, explain
> herself, and to remain cheerful in the face of insults.

I predict you will quickly learn not to encourage the vociferous ignorami.

> * Dawn wrote: “...find that developers are so much more productive when
> working with a MultiValue database”
> and, on her MultiValue flashcard: “Typical relational databases cannot
> match the productivity of the MultiValue database...”
>
> (I'm assuming by “database” you mean “DBMS,” and there are no RDBMSs
> yet, excepting the allegedly excellent Dataphor, which I've yet to use.)
>
> It sounds as if the MV development environment (IDE, reporting tools,
> etc.) is to credit for productivity gains.

What gains? Her alleged productivity advantage is nothing but a myth. She is like a person who claims: "After making very careful measurements, we have determined that horses are more productive than cars. A man can ride a horse ten miles in far less time than he can push a car a similar distance."

> * Dawn wrote, on her example MultiValue flashcard: “They [relational
> databases] would also need features such as variable length data
> structures, untyped elements, user-defined vocabularies and custom
> functions specified as metadata.”
>
> “Variable length data structures” are allowed by the relational model,
> which places no restrictions on types (aka domains).

As you notice, her allegation or assumption is false, which renders her entire point meaningless.

> * Dawn wrote: “Also, what is the theory that leads to strong typing and
> fixed lengths that are found in many relational databases?”
>
> The databases you referenced are not relational.

Again, it suffices to note that Dawn is ignorant and is burning a straw man.

> * Dawn wrote: “They [Don Nelson and Richard Pick] based the way the data
> was specified (which I'm terming the data model, but that might not be
> the right use of the term) on how it was to be queried.”
>
> By “specifying data,” I'm assuming you're referring a combination of
> type definition, relation definition (including normalization), and
> constraints.

She refers to exposing every physical implementation detail to the most causual of users and to tying applications to specific physical artifacts. Only the profoundly ignorant can consider such a feature advantageous or productive compared to logical and physical independence.

> * Dawn wrote: “...multivalues crop up in the way people talk and think.”
>
> Perhaps,

I disagree. Sets crop up in the way people talk and think. Multivalues crop up in the way the cognitively damaged or mentally injured talk and think.

> * Dawn wrote: “It [MultiValued platforms] is old, yet could be revived
> as it provides an amazingly productive environment, perhaps because it
> is so forgiving and because it resembles XML to quite an extent.”
>
> I would take resemblance to XML to be a damning attribute until
> demonstrated otherwise...

It suffices to note Dawn's profound ignorance of the Great Debate happening nearly 30 years ago and that the debate proved pick sucks.

> * Dawn wrote: “It appears there are lower initial costs and lower
> ongoing costs for companies using the MV platform over a more standard
> RDBMS (Oracle, SQL Server, etc.)
>
> For initial costs, I can't say

Again, it only appears that way to the intellectually crippled. Her quackery is no different from the homeopaths who think water remembers. I highly recommend _How We Know What Isn't So_ by Thomas Gilovich ISBN: 0029117062.

Otherwise, it suffices to note that Dawn is an ignorant quack.

> Dawn wrote: “Of what are we [those who would use XML] ignorant? Of some
> theory or practical advice?”
>
> Possibly the theory, or possibly of the practical value of the theory,

Every principle of sound data management and of sound application design.

> * Dawn wrote: “It is easy to understand why it is so common when we see
> that it [a 1-many relationship] is also a generalization of the
> relationship between a relation and an element in the relation.”
>
> First, see the dangers of dividing relations (predicates) into
> “entities” and “relationships.” And keep in mind the excellent analogy
> from Hugh Darwen: “Types are to relations as nouns are to sentences.”
> Types (domains / attributes, sort of) are the things we can speak about;
> relations are what we can say about them. Since you refer to language
> all too frequently in referencing MultiValue, the noun/sentence
> distinction should strike a chord.

She is a vociferous ignoramus with an axe to grind. She is impervious to reason and logic.

> * Dawn used an example of people owning cars and bikes, and how in
> MultiValue the cars and bikes could be multi-valued attributes of the
> person.
>
> This might be OK

No, it's not. Search on "red blue car"

> * Dawn wrote: “...the cascading deletes for referential integrity are a
> no-brainer...”
>
> They are in relational too, and even in SQL.

Triggered operations of any kind, in fact.

> * Dawn wrote: “...switching cardinality of a data element in a
> maintenance phase (or post-design) of a project is very easy to do,
> breaking very little.”
>
> Only if the data element isn't involved in actual logic (e.g. the text
> examples like car names I usually see in Pick examples).

Search on "red blue car". Her assertion is fatuous and demonstrates her unwillingness to acknowledge the serious flaws in the model she espouses. Like every vociferous ignoramus, Dawn lives in a fantasy world of denial.

> * Dawn wrote: “The database tables could still be stored as in an RDBMS,
> but show themselves to the designers and developers in this more
> intuitive format.”
>
> Intuition is a poor basis for logical and data decisions

Any usability expert will tell you that intuition is complex and unpredictable. Any statement to the above effect requires careful empiricism for backing. In fact, this is true of any complex result of biological origin.

Frankly, Dawn is simply an ignorant making an absurd claim.

> * Dawn wrote: “...a column constraint specifying the maximum length of
> an element value might be easy for the computer to do, but doesn't make
> all that much sense when it comes to all of the integrity constraints
> one might put on a field.”
>
> Agreed. The “type constraint” you mention isn't one; it's because the
> non-relational SQL doesn't offer real type definition

It suffices to note that Dawn is an ignorant tilting at the windmills of her imagination.

> * Dawn wrote: “Simplicity: All data are strings with additional type
> specifications for external purposes only. Not only simple to specify
> but to maintain!”
>
> This places the burden of maintenance in every program that uses your
> file/table;

It also exposes her deceit regarding productivity. By ignoring integrity and by discounting the cost of corruption, she pretends--in her own mind--that she can increase productivity as if the only measure that counts is the time until the first compilation that reports no errors instead of the time until the system runs correctly.

> * Dawn wrote: “No need to logically retrieve multiple tables when
> concerning yourself with a single proposition, simply because the
> proposition has conjunctive clauses.”
>
> The hierarchies that MultiValue allows you to establish aren't single
> propositions

It suffices to note that Dawn is an ignorant who fails to comprehend even what she, herself, writes.

> * Dawn wrote: “...but the only meat I can find is related to practical
> issues regarding integrity constraints – not enough to write off the
> entire MultiValue platform nor XML.”
>
> On the contrary: integrity constraints, and types, define not just the
> spine but the skeleton and muscle of your application.

Again, it suffices to note that Dawn is an ignorant making absurd, nonsensical statements.

> Dawn wrote: “...instead of a programmer coding some procedural code (!)
> specific to a certain circumstance, the logic is declared in the
> database, but designated as a local constraint where the next developer
> working with the database might not want/need to apply it?”
>
> Can you give an example?

If the data require the constraint, it doesn't matter whether the next application programmer who comes along finds the constraint convenient. The constraint keeps the fool from corrupting the data.

If requirements have changed, then it is much more productive to reflect that change in one central location, ie. the database, than in every application. If the change is such that it will require changing applications, it makes sense to centralise the error-detection logic to prevent costly mistakes in one application from damaging all the others.

Dawn is a chronic ignoramus whose nonsense does not warrant a reply. Received on Wed Feb 18 2004 - 19:40:14 CET