Ken,

I too spent a lot of time deciding on a system for field names. The conclusion I reached was this:

Why add a prefix to a field name when it's a member of a named container (the table)? Customer.FirstName and Employee.FirstName are absolutely two different data items. Why not use field names that represent the data they contain?

You can gain some real benefits in data manipulation code by using simple field names. Example: A single, simple stored procedure to generate a list of names (employee, customer, etc.) can be written where the only parameter furnished is the table name and possibly a partial search string. You can do something similar if you prefix the field names but it complicates the code.

The same rationale applies to PK's. All my primary keys bear the same name. Foreign keys are named FK_ plus the name of the table they point to. There are coding advantages to this also.

Just my thoughts on the subject, you need to do whatever you're most comfortable with. Regards.