Re: Argument for 1NF by counter-example

From: Laconic2 <laconic2_at_comcast.net>
Date: Sun, 24 Oct 2004 09:03:26 -0400
Message-ID: <aoednQd22pO1NebcRVn-jQ_at_comcast.com>


"Kenneth Downs" <firstinit.lastname_at_lastnameplusfam.net> wrote in message news:emuelc.ivc.ln_at_mercury.downsfam.net...
> Have been following these conversations on 1NF, atomicity, types vs.
> relational and so forth. Very good reading overall.
>
> I have an example from real life that seems to suggest Codd's original 1NF
> is not ready for the grave just yet.

SQL isn't ready for the grave just yet, either. But it's ready to join COBOL, AM Radio, and the reptilian nervous system as "no longer on the leading edge". My position on SQL is simple: I used it because it was there. By the time I switched over to SQL from another interface language, I was working for "clients" rather than "employers", but the difference is unimportant in this context. I learned SQL before I learned of its defects. Big deal. I learned FORTRAN before I learned of its defects.

With regard to atomicity, SQL is locked into a non comprehension of domains that are sets. I'm not about to learn tutorial D, but I suspect that, given what I've heard derived from the manifesto, that it is not simlarly locked in. That might be a place to start, in a search for the next step in languages.

Will tutorial D become the basis for a new breed of languages? That depends on a lot of factors that have little to do with its advantages and defects.

>
> A colleague of mine wrote a report writer. Each report was stored in a
> single row in a table. The table had plenty of type 'text' columns
(clob's
> in some dialects) that contained comma-separated lists. One list of
> columns, a list of the order-by columns, a list of the group-by columns,
> and so forth. Each new feature tended to lead to another text column and
> another comma-separated list.

By "locked into a non comprehension" I mean that hiding a CSV inside a text is just hacking away at the limitations of the language.

A report writer tends to benefit form the "everything is a tree" paradigm. Using that paradigm, you don't have to hide the CSV at all. You can just epress the CSV as a list, and place the list wherever it belongs on the larger scheme of things.

> This may seem like a very basic question, but if we relax 1NF in practice,
> don't we lose some very basic abilities with SQL?

Yes. But what you do with this fact depends on what role you play. My role is "SQL user". (My use of the word "user" here includes but is not limited to the role "programmer") As such, it means hanging on to SQL for the sake of the abilities it gives me.

If your role is, on the other hand, "interface language designer", what you do is very different. You devise a very formal, and very explicit list of exactly what those abilities are, and their interdependencies. You then decide which of those abilities is expendable. You also make up a list of abilities that are "designed out" by the present language, but that you want to include.

You then come up with a language that captures the requisite abilities, has a minimum of "unfortunate language features", is easy to use, easy to learn, easy to write fast software (compilers and interpreters) for, and integrates well with the rest of your information paradigm.

Easy to say, hard to do. Received on Sun Oct 24 2004 - 15:03:26 CEST

Original text of this message