[dba-SQLServer] ANSI null compliance

Stuart McLachlan stuart at lexacorp.com.pg
Mon May 9 17:45:20 CDT 2005


On 9 May 2005 at 17:49, Arthur Fuller wrote:

> You have just cited the exceptions which IMO prove my point. Those 
> columns should be nullable for exactly the reasons you mention. 

In my experience, far more fields need to be nullable than not, so the 
default is appropriate in my case.

> My point 
> was that an employee without a surname is a problem, and similarly 
> without an SSN or SIN or their international equivalents. 

No such international equivalent in PNG :-(  

Personnel databases are a nightmare here, not only is ther NO unique 
identifier such as an SSN (there is no Social Security), people change 
there names at will (often when someone dies, their nephew will adopt their 
name etc), in many areas, they use only a few distinct names within one 
locality and they interchange first and last names ( Tau Buruka is Buruka 
Tau's son, there are lot's of  others with either Tau or Buruka as a last 
name)

A significant proportion of the population, especially the older generation 
don't even knwo the year of their birth, let alone the date. Very few 
people have birth certificates.

Add the fact that employers frequently recruit staff using the "wantok"* 
system so a lot of the staff come from the same locality, are related and 
have similar names.

*Wantok = "one talk" literally a person who speaks the same language as 
you; there being about 800 languages in PNG.  Effectively a wantok is a 
relative or someone who comes from the same tribe/clan/localtiy as you do.  
Without any form of government social security and being a very triabal 
society, you have to look after your wantoks and you expect them to look 
after you.

> Certain data 
> must be there. Other data is optional. But in the case that you cited 
> (missing home phone) I would try to devise a system (stored proc or 
> whatever) that assigned this row a status of "missing important data" 
> and automatically revisit these faulty rows so they can be corrected.
> 

I find it much easier to just use the built in staus of "no data value" ie 
Null.   It is then easy to identify the fields which contain "important 
data" and list those records with Nulls.   No need to develop any 
system(stored proc or whatever). 

-- 
Stuart





More information about the dba-SQLServer mailing list