Re: Proposal: 6NF

"Roy Hann" <specially_at_processed.almost.meat> wrote in message news:k9udnQPr6v8p2bvYRVnyrQ_at_pipex.net...
> "David Cressey" <dcressey_at_verizon.net> wrote in message
> news:o1rVg.851$Ye.584_at_trndny04...
> >
> > "Roy Hann" <specially_at_processed.almost.meat> wrote in message
> > news:JbqdnVhWQvBlk7jYRVnygg_at_pipex.net...
> >
> > Either that or people want to read crappy reports. How much or how
little
> > you loathe the way ordinary people approach the data is as much a matter
> > of
> > culture as it is of logic.
>
> Actually I have no particular problem with the printed result. People,
> including me, are perfectly accustomed to see printed reports with lacunae
> and whitespace, and we make of it what we will. However the whitespace is
> not null, it is just whitespace, and crucially that is where it ends. The
> report is not a table in a database and there is no means nor temptation
to
> misuse it as the input to further productions within the database.
>

Well put. I particularly like the use of "lacunae" and the phrase "make of it what you will".

for the sake of example:

We want a report of each salesman with some details for each sale the salesman closed during the month.
What about salesmen that closed no sales during the month? Yeah, they should be included.
What should we put in for sales details in this case? Nothing.

First point: when I first started producing reports like this, I didn't have an outer join available to me. So I had to do it the clumsy way, by taking the union of the inner join and the set of salesmen without any sales. I suspect that this union is just as "non relational" as an outer join is, but I'm going to defer to the mathematicians in the group on that score.

Second point: I can't recall EVER using an outer join, other than in the context of generating a report, or perhaps some extract that, for our purposes here, can be considered the moral equivalent of a report.

Third point. I extend your concept of "lacunae" to NULLS in tables. A NULL in a table simply indicates a lacuna in the data. It means nothing more than whitespace in a report. Make of it what you will. It's the database designs that assign a "conventional meaning" to a NULL, as if it were a message, rather than no message, that get into trouble, IMO.

Having said that, the question arises of what to do when an application tries to do an insert, without providing a value for every column in the table. Some people would have the database server always reject such an input. Others would have the database server always substitute a default value, drawn from the domain of possible values for that column and specified somewhere in the metadata. Others would have the insert always succeed, and put a NULL in where no value was specified.

My answer is: It depends. What are you trying to do with the data, and how do you want your systems to behave?

More later. In the meantime, again, well put, Roy. Received on Fri Oct 06 2006 - 15:36:18 CEST