2) Whenever possible, if two tables are related by a common key field, name the fields exactly the same in the two tables. It drives me crazy when some DBA figures I can intuitively deduce that EmpID in one field is the key to the field UserNum in another table.


It drives me crazy when someone has given columns in different tables THE SAME NAME ... grrrr.

I take your point about totally incongruous names for these keys, and sure you can argue that aliases provide clarity on cases where joins are combined with groupings etc, but as a someone that usually has to clean up someone else's mess, this is one point of style that makes my brain ache when im trying to decipher old code.

If you have a foreign user key in your order table, call it PKUserID in tblUser and FKUserID in tblOrder. (and prefixing tables with tbl in Enterprise Manager helps group _your_ tables away from the annoyingly listed system tables ... and prefixing stored procs with stp too come to mention it ... but i digress ...)

I don't want bash any bibles, but these four points from the Art of Unix Programming (http://www.faqs.org/docs/artu/) sum up the feeling im trying to get here. (good solid sensibles guidelines when writing code of any type really ...)

Rule of Clarity: Clarity is better than cleverness.
Rule of Transparency: Design for visibility to make inspection and debugging easier.
Rule of Robustness: Robustness is the child of transparency and simplicity.
Rule of Extensibility: Design for the future, because it will be here sooner than you think.

But wait .. there's more (nod to Demtel .. im an aussie ... the more code you say you have to write, the more $$s you earn! And to top it all off, an ounce (or $1k) of prevention is better than a pound (or $20k) of cure!!

I just hope people actually read this stuff ... kinda outta date, but ...