Hi david,

In regards to Joe Celko, well everyone might have a different perception on what is good or bad. My personal comments on this

>For example, null-tolerant columns are not on his most-favored-habit list. In the case of string and numeric columns, I would agree – better to have specified default values to prevent issues with nulls in calculations and searches. But, since an empty value is not valid in a date column, how else do you indicate the absence of a value, other than with a null? Same with foreign key columns.

There are different strategies. Personally I use the value of zero for foreign keys. For some applications (because of VFP history reasons), I just use the default value assigned by SQL-server when passing an empty date. The framework translates this date into an empty date.
However in numeric data, I do use NULLs frequently. Esspecially in scientifical applications, where you have to make a distinction between absent or non applicable values and zero values, it makes great sense for calculation purposes.

>Another surprising declaration was that use of the IDENTITY column value for primary keys is bad. I was not the only one to do a double-take on this, as it is (at least in my view) one of the easiest ways to implement surrogate keys in SQL Server. Celko’s beef with them is a lack of validation and verification (I didn’t really get his point on that)

Identity columns do have problems. I fullheartly agree with joe to avoid identity columns. They present problems as an identity column generally prevents inserting manual values. Esspecially from a scalability standpoint where you have to use replication you'll have to jump through hoops to avoid problems. Further there are problems when you want to insert parent and child records in one transaction. Since you don't know which value SQL server will assign to the PK of the parent, you won't know what value to assign to the FK in the child table. Personally I use a Newkey stored procedure to generate new keys. While identity columns seem an easy choice at first sight, it might catch you later when things start to get a little more complex.

AFAIK, Joe indeed is a fan of using natural keys as oposed to surrogate keys, however keep in mind that natural keys can be autogenerated keys as well. For example an invoice number, order number, Packing list no, are not surrogate as they do have a meaning outside of the database and therefore you should not conclude all too easy that using natural keys means multiple column PKs in all cases. Personally I use surrogate keys in most cases, but I definitely see advantages to natural keys as well.

>Lastly, he had some unkind words about people that confuse “records” with “rows” and “fields” with “columns”. Huh? Sorry, Ashton-Tate and Microsoft used the terms “record” and “field” for years, and the habits of old dBase and FoxPro developers die hard. I’ve worked with SQL for eight years now, and still mix the terms up. Joe, if that makes me less of a person in your eyes – too bad. It also cost you a fan, but with 750 articles to your name I suppose you don’t really care, do you?

Hmmm, a lot of emotion. Well, indeed the terms like tuples, rows and records are used interchangeble, as well as field, column and attribute. I don't see the problem in that. Everyone know what you mean by record and field (though one might argue that a field is a column in a single record), and well if the purists have problems with it, I don't care. My applications won't break on it, my communication with other people does not suffer from it, my commercial business does not suffer, so who cares ?

Well, this is always the problems with guru which also act as guru. CODD and DATE had fundamental different opinions of the use of NULL values. But I learned a lot from DATE in his books. Just take out what you need, and ignore the rest (grow your own opinion). Sometimes, you only realize the rational afterwards (days, weeks, years). The guru, might have poorly explained his thoughts (or you poorly understanded his thoughts), but it will pop up at a moment when you're working on a certain problem. But also keep in mind that 'Guru can be wrong also'.

Walter,