Re: XQuery (and XML) vs LISP

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 databases certainly do have tables for things like employees and departments, so it certainly is the case that lots of people do that sort of thing.

> 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? Such as would be hundreds of thousands of lines of code long? Of *course* they don't. They don't in any other field, either.

> 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. You don't see books on Perl focusing on object-oriented programming; you don't see books on SQL focusing on String processing, and you don't see books on auto maintenance showing you how to use a socket set to drive nails.

There are some things that SQL does extraordinarily well. Handling data in static hierarchies such as employee/deptartment or customer/invoice/line item is something SQL does better than anything else. Handling dynamic hierarchies, like a parse tree, it has a harder time with. Should we reject a tool because it doesn't do everything well, or should we instead just use it for what it's good at?

> >If one belongs to the crowd that says, "I want a J2EE book, and
> >the more it weighs the better it must be," one probably does
> >not appreciate this perspective.
>
> And I'm sure it rains on Mondays in Sweden, depending. Which
> has what to do with what?

A good demonstration of something is a minimal demonstration of something. When I want an example of how to do something, I want it small; that will make it easier to understand. This is especially true when teaching new concepts. That's why SQL books show the employee table as having 5 employees in it; if it had a hundred, the concept would actually be *less* clear because it would be obscured under all the data.

If one (metaphorically speaking) supersizes ones mental fries, one won't appreciate this.

Furthermore,

If one belongs to the crowd that says, "I want a J2EE book, and the more it weighs the better it must be," one probably does not appreciate this perspective.

> >> To normalize things does
> >> it require literally hundreds and hundreds of 'relations'/tables to
> >> represent the structure?
>
> >How many classes does a Java program have? How many
> >people does a company need?
>
> 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.

> >> 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? And the answer is, the number of tables that produces the fully normalized schema.

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.

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

It's just a mental fixation, and not an actual problem.

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

> >> 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." But I could be wrong. Could you perhaps rephrase this?

Or else perhaps if you disagree with the necessity of structure, could you perhaps show me some example of some data that you could meaningfully use that didn't have any structure.

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

Marshall Received on Sat Feb 18 2006 - 07:29:27 CET