>>>>There is one important problem in this code sample - the OrderDate is not prefixed with the alias. Without that we would need to check which table this column belongs to.
>>>>My rule of thumb - prefix every column with an alias name when the query involves more than 1 table.
>>>
>>>I don't disagree with the rule of thumb, especially with several tables. But with 2 tables (a business entity master and a child table of orders), any question about the lineage of OrderDate is more likely a problem with the person in the chair. :)
>>>
>>
>>The rule is the rule - and I always follow it.
>
>My rule says that all fields within a database have a unique name by having a three letter prefix and an underscore for every field in a table, therefore not needing to prefix any field with an alias. As a bonus in the result of the query you always know where the field comes from.
>
>Walter,

Walter, I'm not trying to play word police, but what you're describing is a practice/methodology, not a rule.

(Actually, what you described is kind of interesting, hadn't thought of that approach)

I rather doubt that if I came along and created a table in your database, it would fire off validation errors....unless you tell me you've wrapped a rule-based DDL trigger engine around your database...then it might be a rule.