The basic table naming convention I try to follow is... what does one row contain? Does it contain a Customer or Customers (answer should be obvious, there)? Same for User, Officer, etc, etc. I also generally try to stay away from "User" because it's a reserver word.

For lookup, definition, or reference tables (whatever you prefer to call them), I follow the ol' "parent table" naming convention. For example... If I have a table called "Customer" and I want to include a custom "type" (ie, business, residential, internal, etc) column in the Customer table (would normally be a CustomerTypeID column), the name of the table to find the ID/Name cross reference would simply be CustomerType and it's primary key column would, in fact, be CustomerTypeID.

For disassociated (ie. General purpose) lookup tables, the name would obviously be a table name with no embedded parent. Further, in order to differentiate between internal "ID's" and "Code's", such as the 2 letter abbreviation for a State or Province, I may have a table called "State" which may or may not have StateID, StateCode, and LongName columns.

Ok, duck... here come the natural key zealots... 😛