Ken,

I'm with you on a few, but I agree, adding the xx_ to each field name so you know what table it belongs in, I don't like that, but don't see how it would hurt you.

For PK/FK, we just use the table name with _id after it... Like we have customers and customer_id,

In the invoices table with a PK of invoice_id would have a FK back to the customers table, it is still named customer_id... This makes joins alot easier... also, another reason we did this is that Crystal Reports uses same name fields to do joins.

Also, one thing we didn't do, that I would do in my next app is to use User Defined Types... this way, you don't have to worry about changes messing up things... So, if you have a data type "fname" and you use that for all your first names, if you change its size, all your firstname fields change.

BOb




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