It's all matter of personal preferences and style of programming. You should find one that suits you the best and stick to it.

>All,
>
>I have debated with myself for years over field naming conventions - first in FP/VFP - later in SQL Server. I am getting ready to build several new applications and want to re-examine my standards one final time before proceeding. I and would appreciate any opinions anyone has.
>
>My current method involves designating a 2 or 3 character identifier for each table - for example the 'customer' table might be 'cs' - invoice might be 'iv'. All fields are then named 'cs_something', 'iv_something', etc. Pkeys (always surrogate integer) are named 'cs_id'. Fkeys - by convention, are named like 'iv_csid'.
>
>The advantages/pros to this - which is why I use it - include:
>- all fields are instantly identifiable with the table they belong to
>- pkeys and fkeys (and child/parent table) are instantly recognizable
>- code can "count-on" standardized naming of keys and interpret if a field is a key and what kind if necessary
>- no confusion or need to specify table names when doing joins
>- little to no chance of using reserved words/commands for field names
>
>The cons - which is why I might be open to change include
>- can run out of meaningful 2/3 character identifiers in large databases
>- a little more typing when entering field names is required
>- and perhaps most importantly - this seems to be contrary to "industry standards" to some degree and is not easily or well supported by most case tools I've seen - especially for auto-migration of keys, etc.
>
>I'll look forward to hearing opinions on this.
>
>Thanks,