>>We are converting to a SQL Server database, and were debating whether to have the primary keys default to zero or null. What are the advantages/disadvantages to each?
>>
>>Hi, Jerry, I disagree in concept with the notion of zero or null keys - especially in (but not limited to) data warehousing scenarios.,
>>
>>For instances where a business entity is null (like for instance...5% of your orders don't have a cost center), the recommended practice in most data warehousing circles is to store an "undefined" cost center in the cost center master....and then use that PK in the orders table.
>>
>>If you ever take your database and utilize analytic tools down the road, you'll be glad you took this approach. (Conversely, some wind up regretting the use of NULLs when building OLAP databases.)
>>
>>NULLs and zeros really don't belong in PK/FK relationships. Nothing to gain, and potential problems down the road.
>
>Hmmm, food for thought. My instinct is to say an unknown cost center should be stored as Null, not assigned to a bogus cost center. To me that's the definition of Null -- we don't know. Maybe your way makes it easier for OLAP tools and you are approaching this from a practical rather than theoretical POV.

Quote from one of the replies in the mentioned Quiz:

---------------
“…My friend Louis Davidson argues that it’s better to make the foreign key not null and add a row to the lookup table to represent the Does-Not-Apply value. I see that as a surrogate lookup and would prefer the null.“ [“Microsoft SQL Server 2008 Bible” by Rolf Nielsen]

----------
So, if the above quote is correct, it means the great authority in Database Design suggests to avoid NULL usage for FKs.