Re: XQuery (and XML) vs LISP

"Marshall Spight" <marshall.spight_at_gmail.com> wrote:

>Mark Johnson wrote:
>> "Marshall Spight" <marshall.spight_at_gmail.com> 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.

>> >Employees and departments are tables that will exist in a
>> >(probably relational) database in the HR department of
>> >every corporation in the world. It is about as real-world
>> >an example as you can get. It may be the case that
>> >you don't write applications that do that sort of thing,
>> >but lots of people do.

>> No they don't.

>HR

I don't care - what. You took me out of context. This is what I wrote, instead:

>> Such examples that are shown are trivial. You don't pay
>> someone to do something that easy, that simple.
>> A real world requirement isn't anything like that.

>You mean, you're reading books that aren't showing you
>full blown HR systems?

And that's a straw man. That's not what I said. But at least we agree that the examples typically shown are pointlessly trivial. Actually, it's a common complaint against academics.

And:

>> And I still think that you particularly don't see certain examples
>> because they might seem to be counter-examples of entire scheme.

>Of course. When you're writing a book about a technique, you
>show what it's good for, not what it's bad for.

Sounds more like promotion or salesmanship. You only hear about what was wrong with last year's model when it comes time to sell next year's model.

>There are some things that SQL does extraordinarily well.

In fact, wasn't it one of Codd's rules that SQL be the means of manipulation, rather than some other sort of code, in addition?

>I want it small; that will make it easier to understand.

But there's a problem with that. One of those is - scale. How does it scale? Does it scale? The subject, here, is technical papers and presentations. And in addition, do the trivial academic examples conceal a fundamental problem with the approach? Does it work only narrowly and in the most simply contrived situation, even regardless of scale?

>> Do you disagree with that idea that a more normalized scheme tends to
>> increase the number of tables?

>Not at all. For any schema, there is a schema with the equivalent
>information that contains only a single relation. Such a schema
>will maximize the potential for update anomalies.

I was simply saying that relations tend to multiply, and so joins.

>> >> Just think of the 'joins'.

>> >Joins are wonderful;

>> Most anything to excess ceases to be wonderful,

>This statement relies on the word "excess." The real
>question is, what is the *right* number of tables?

That IS a good question. But it goes to what is a - type, I think.

You may think it's a sort of pointless question. I don't know. Just throw in whatever 'sounds good', and call it an entity?

>Tables and joins aren't an expense to be minimized.
>Columns aren't something you want to be sure to have
>the fewest of, no more so than rows.

In other words, what if an attribute doesn't belong?

>One runs into this same idea in the Java forums sometimes.
>Someone has a problem with a class; someone else shows
>them how their problem may be eliminated by decomposing
>the class into two classes; the OP rejects that solution
>because, you know, "too many classes."

Alright. Classes/parameters/processes/etc.

An 'instantiated' class is created in one or more processes, before anything else, let's say. Following the book question, what's the scheme for that? A process might apply to the class, but also to another class. But is the process properly part of the class relations, or is a linked set of relations specifying class more properly a thing that belongs with the process relations? Is there some convention that's been used, for any particular reason? Maybe this question has been trivially answered, and years ago. It's not that one can't view class in terms of process, and vis-versa, from the same data. And I understand it, that supposedly is a benefit of RM. But why does what go where in the underlying relations? Does it matter?

>"Just think of the joins" is the same non-problem as
>"too many classes."

They're not comparable. And are you suggesting that a SQL statement consisting of many joins would not seem rather cumbersome, and even prone to error for that? But with more discreet relations, isn't such an excessive string a possibility?

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

>> >No.
>> >And anyway, you can't not have structure.

>> No, of course not. Structure. It's transcendent. It transcends any
>> scheme. Any scheme has to represent that structure, that order.
>> Obviously. Or else it's representing something else.

>I had a hard time with this paragraph. I'm not at all sure
>I understand what it means. As near as I can tell, what
>it's trying to say is "nyaa nyaa nyaa, nyaa nyaa."

Gloating or boasting - about what? How could it be, even as an outside possibility? Maybe you're thinking of some other message or thread?

Rather, I was merely agreeing with you. Structure is transcendent of any scheme. The scheme must represent that structure, or it represents something else. I can't state it more clearly than that.

>> But wasn't the idea to separate out any fixed structure by reducing a
>> very well-defined scheme to a series of connected relations? Wasn't
>> the idea that while, again obviously, the RM itself describes a fairly
>> rigid structure, it didn't face the problems of an early generation of
>> COBOL, for example?

>> If I misunderstand, then so be it. If that wasn't a typical problem,
>> then what did Codd set out to ameliorate?

>I have no information about the problems of early generations
>of COBOL, nor do I know anything about Codd's intentions.

I was referring to his rules, and his purpose, and what he thought might be better because of them. Received on Sat Feb 18 2006 - 09:17:15 CET