>In my reading I came across a convention for namining fields in a table that used a 2 letter table identifier followd by an underbar as a prefix to all table field names.
>For example in a Customer table une would finf fields:
>cu_CustCode
>cu_Address
>cu_City
>cu_State
>
>etc. Each table had its fields specified in this manner.
>
>It is clear that there are advantages to this nomenclature in that you can easily identify and distinguish a field in a table from memory variable. There are also advantages in SQL statements.
>
>Doing it however is somewhat of a pain and I am wondering if it is worth the effort.
>
>Does anyone have any experience in using this naming approach?

PMFJI: I have worked in different organizations with both approaches, and personally found that NOT putting a table prefix on the field names is better, for flexibility for future extensions of the application. What if two tables have the same beginning characters in their names -- to avoid confusion you have to use some 'bogus' prefix, and that blows the value of it. Alternately, suppose you want to add a new table for segregating its data, but have the same structure and use the same programs to manipulate it... Having table-name-prefixes pretty well prevents that. I vote for re-usability every time. To paraphrase what Jim Booth said in his reply, a convention that is applied with exceptions doesn't help you...

FWIW: What we DO do, however, is to use a data-type-prefix on the fields in all our non-legacy tables. Have had LOTS of problems with the same field name used in different tables built at different times by different (no longer here) developers that have different data types (and field widths, etc...) that tend to easily break any new work done to extend the functionality of different modules or add new tables, etc. We are addressing that with a better review process and data dictionary usage, but still have a lot of legacy tables that come back to 'bite' us from time to time...

HTH

Rob