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

Ken,
From my POV it's overloading. I even don't like dBirth_Date convention. If it were cBirth_Date might make sense. IMHO table fields doesn't need a prefix. Table names already serve as a prefix - as a pointer better yet. I wouldn't feel comfortable when I say cs_FirstName instead of cs.FirstName, I still would make it cs.cs_FirstName. Only PKFields in my case have a prefix if I can't find a better name for them like EmployeeId (and foreign keys referencing to this table is still EmployeeId).
It's a matter of style and no ANSI for it :)
PS: I really tried similar to what you describe once and it was like tooth pulling when I needed similar structures but different tables/views :)
Cetin