Re: Argument for 1NF by counter-example

From: Dawn M. Wolthuis <dwolt_at_tincat-group.comREMOVE>
Date: Sat, 23 Oct 2004 21:03:48 -0500
Message-ID: <clf2ij$64q$1_at_news.netins.net>


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

It is really quite amazing how many implementations of RDBMS's (or SQL-DBMS's) use a similar approach to nested structures within 1NF. Quite amusing.

> Why they did it that way I cannot say, but personally I would not do that.
>
> The most basic problem with it is that you cannot use SQL to maintain a
> report. You cannot RI the columns against some data dictionary. You
> cannot so the simplest SELECT report_id,column_id from the table.
>
> In short, you must parse the column. If these column lists were in child
> tables, you would once again be using SQL to do 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. I''d suggest that in spite of the efforts of SQL-3, we really do have to ditch SQL to get to the next level with databases. I don' t know who is using the nested structures in Oracle (starting with 8i IIRC) or the parent-child inheritance with PostgreSQL, but I don't think that there is any massive movement in that direction in the SQL-DBMS world. I suspect that a move away from the 1NF of old will include a move away from SQL.

Once XQuery includes update capabilities will that be the language on which to hang our collective hat? Right now I'd give it at least a 70% chance. That doesn't mean that SQL will go away (any more than COBOL has) but that new database implementations will use more flexible structures with an XQuery language, perhaps? Just thinking outloud. --dawn

> --
> Kenneth Downs
> Use first initial plus last name at last name plus literal "fam.net" to
> email me
Received on Sun Oct 24 2004 - 04:03:48 CEST

Original text of this message