Re: XQuery (and XML) vs LISP

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

In that case I have no idea what you are objecting to.

I understood you to be objecting to simple examples, and I assert that simple examples are the best way to illustrate concepts. Certainly they do not make real systems; their purpose is didactic, not practical. That does not mean the concepts so illustrated are not practical, though.

Consider the original K&R "C Programming Language." All the programs in it were quite small and limited. A simple hash table, for example. Yet the book is a classic.

> But at least we agree
> that the examples typically shown are pointlessly trivial.

Since I went on at length about what I thought was valuable (which is to say, the opposite of pointless) about simple examples, I don't see how you could reach that conclusion. In any event, let me be explicit in saying that I do not consider the typical employee/department examples used in SQL books to be pointless; on the contrary they are quite valuable.

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

What's wrong with that? If you have a useful product, you still need to promote it. No one's going to find out about it by reading your mind. You promote something by showing what it's good for; any other choice is ineffective.

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

Why did you excerpt my "There are some things" sentence and follow it with what you did? It seems a complete non sequitur.

And as I said, I have no particular desire (nor ability) to discuss Codd.

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

It turns out that SQL scales quite well, both in the complexity dimension and in the data size dimension.

> The subject, here, is technical papers and presentations.

It is? When did it become so, just with this sentence?

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

I don't understand the purpose of these questions. Are they rhetorical? It seems fairly clear that the answers to these questions is "no."

Do you have any experience with SQL?

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

Yes. Software tends to grow in complexity as we add new features and functionality, and capture more data.

If we program in an OOPL, the number of classes goes up over time.

If we program in an FPL, the number of functions goes up over time.

This is a good thing.

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

What is a minus type? I don't understand the purpose of the dash in the above sentence. Are you just asking "What is a type?" If so, please allow me to refer you to Benjamin Pierce, "Types and Programming Languages."

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

Could it be that when you ask "what is a type" what you're really asking is, how do we define tables? (I say this because you mentioned the word "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?

Then you put it where it does belong.

Am I to take it that you haven't done much data modelling?

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

I really had a hard time understanding this paragraph. It sounds like you're asking how table design is done, but I could be completely wrong.

> >"Just think of the joins" is the same non-problem as
> >"too many classes."
>
> They're not comparable.

I can't think of a difference. Can you? Both are aesthetic responses, not technical ones.

> And are you suggesting that a SQL statement
> consisting of many joins would not seem rather cumbersome, and even
> prone to error for that?

For me, calculus seems cumbersome and prone to error; is this a flaw of calculus, or a limitation of mine?

Let us imagine a SQL select that joins ten tables. We must ask why does it do that? If it is because it answers a complex, difficult question that involves quite a lot of different sources of information, then it is hard to see what the objection is. In essence, any objection to the SELECT would really be an objection to the question being asked. We have a choice: we can answer the question, complexity and all, or we can say, "that question is too hard" and then we don't have to deal with the ten way join.

And of all the ways I know of to answer a question that might be answered with a ten-way join, the ten-way join seems the least error prone among them.

> But with more discreet relations, isn't such
> an excessive string a possibility?

Again, it's not "excessive" if that's what's necessary to get the job done. Complicated problems often have complicated solutions.

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

It's clear to me that we use quite different communication styles. I sometimes have no idea what you're saying, even when you think you're being very clear, and you sometimes don't follow what I'm saying, even when I think I'm being very clear.

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

Okay.

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

Sure. I'm just saying I don't have much to contribute to that discussion.

Marshall Received on Sat Feb 18 2006 - 10:25:05 CET