Re: Argument for 1NF by counter-example

"Dawn M. Wolthuis" <dwolt_at_tincat-group.comREMOVE> wrote in message news:<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.
>

I don't think you can necessarily blame old-style 1NF, RDBMS' or even (God help us) SQL for this; it sounds like a design that was just about adequate to start with (or seemed like a good idea at the time) which has had it's weaknesses amplified over time by new requirements. I daresay you can come up with duff designs whatever tools you use.

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

I'd suggest that *because* of the efforts of the various SQL:2003 standards committees, we'd best look elsewhere for the next level of database work. Some will drone on about Tutorial D, but I can't admit to being a fan. Personally, I'd like to see the next generation working from a declarative direction; either from Prolog or alternatively something like Haskell plus relations. Haskell + relations would have the distinct advantage of giving us a very flexible, working, proven and mathematically respectable type system too.  

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

XQuery et al have built up such a head of steam that they will probably garner some level of acceptance. Pity help us all.

Some years ago, at a rather drink fuelled discussion, a group of us came to the conclusion that FORTRAN 2010 would be a fully functional programming language with a polymorphic type system, but that every compiler would have a "-F77" switch for full FORTRAN-77 compatibility. In a similar way, I think we'll end up implementing XML databases, and XQuery and the rest, and in 20 years someone will reinvent relational theory and say "hey ! let's give this shiny new thing a try ..."

I'm only feeling a little cynical today ;)

Cheers,

• Tony