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

Yes - they ARE different items - which adds support to thel ogic of habving a differnt name!
I would also go back to arguments of not needing to specify table in joins and - a BIG one - not stomping on reserved words.

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

see - I'm very happy with my pkey fkey logic - 'cs_id' is pkey and 'iv_csid' id fkey - from just seeing 'iv_csid' I know immediately that it is a foreign key in the invoice table that points to the customer table. My concern has been "non-industry compliance" - not any functionality/usage issue - but your pkey/fkey method would have the same problem.

thanks for your opinion!