Ken,

Check the discussion around the Wiki article http://fox.wikis.com/wc.dll?Wiki~CategoryNamingConventions

Personally I don't like embedding table names inside the fields themselves. I like single character datatype prefixes. Over time I have used two different conventions for PK and FK fields: 1) the PK was always named iID the FKs were iTableNameID and 2) the PK is ThisTableNameNo and the FKs are OtherTableNameNo. If the table doesn't have a single field for it's PK then the above rules don't apply because the PK ends up being two fields like TableNameOneNo and TableNameTwoNo.

>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.