Ok Anup,

A table must have at least one Key that is meaningful to the business.

An "Artificial" key ( Identity, guid, rownumber ) is probably not a meaningful business key,

and if a table has such Artificial key it must also contain at least 1 UC ( Unique Constraint )

that IS meaningful to the business.

So if You have any DB designers at your place with "bad" habits ( using only meaningless keys ),

please ask them to review the relational model and learn some fundamental DB design concepts.

"Artificial" or "Natural" keys?

Well IMO both work, and there are situations where one works better than the other.

It depends on the database and the business area(s) it is supporting.

A table without a key is not a table at all, more like a heap where You can store a bunch of rows.

The article was OK, interesting. Describing one technique to accomplish a "comfy" select from (self)related tables.

You could do similar things with views ( and you don't have to add computed columns! )

/rockmoose