Re: XQuery (and XML) vs LISP

From: Mark Johnson <102334.12_at_compuserve.com>
Date: Thu, 16 Feb 2006 22:19:26 -0800
Message-ID: <32qav1t46vavk66j978uk7nd62ijtltuor_at_4ax.com>


Frank Hamersley <terabitemightbe_at_bigpond.com> wrote:

>Mark Johnson wrote:

>> The thing that has bothered me is that those promoting the relational
>> model typically provide worthless examples, typically employee and
>> department, and seem to almost religiously avoid non-trivial working
>> examples, particularly those that might seem problematic for the
>> scheme.

>Its the same reason that babies get fed milk first, mashed food later
>and finally solids!

But those aren't babies reading those texts and articles. Babies don't read all that well to begin with. You seem to have avoided the issue, here. And there's that "particularly . . . problematic', bit. That sort of explained it, for me. I don't know if you differ.

>> For example, what is a type? What goes in the 'set', as you express
>> it, never mind any particular domain? Why is a book a 'type', when
>> there are various sorts of books? Why is a chapter a 'type', when the
>> chapters in the same book might be of a very different sort? Is the
>> appendix which is more an index a type to itself? And so on. Are the
>> paragraphs a 'type', and is the paragraph in chapter 4 different than
>> the paragraph entities in relation chapter 5? To normalize things does
>> it require literally hundreds and hundreds of 'relations'/tables to
>> represent the structure?

>Have you seen "hundreds and hundreds" first hand? What were they
>responsible for expressing?

Structure. Pascal says much the same. More nomalized, more tables. And what about all those joins?

>> Just think of the 'joins'. And wasn't the RM
>> intended to free people from the 'tyranny of structure'?

>Nope - where you get an idea like that?

Because that was the idea behind it. But the difference was that, if I recall, the structure and programming went together in the 50s and early 60s. They weren't separated out. Just generally, a lot of development has been had because parts of processes have been separated in a 'workflow' scheme. For a simple job, it seems excessive. For anything else, it simplifies, compartmentalizes and reduces error. And there have been a lot of decades between then and now. And the RM has been implemented to certain degrees. Now if you put such a hierarchy on an existing RM or pseudo-such, it seems as if it would be a different matter - even while violating the basic tenets of the RM to do so. But it's not necessarily tied to a structure, as the RM is so tied by joins and the relations themselves. And it makes structural modification difficult.

Remember what I said: For example, what is a type? What goes in the 'set', as you express it, never mind any particular domain? Why is a book a 'type', when there are various sorts of books? Why is a chapter a 'type', when the chapters in the same book might be of a very different sort? Is the appendix which is more an index a type to itself? And so on. Are the paragraphs a 'type', and is the paragraph in chapter 4 different than the paragraph entities in relation chapter 5?

>The aim is to "improve" the
>structure and still make sure that physical aspects don't (irrationally)
>impinge on the logical interests.

I'm not sure that means anything. Improved compared to what, precisely? And why irrationally in parentheses, etc? Could you elaborate? Received on Fri Feb 17 2006 - 07:19:26 CET

Original text of this message