I have a table called operators. Each operator (operatorID) will have employees but the number will vary from 1 to n. So, my thinking is that I should create an employees table that includes all employees for all operators, using a compound key including operatorID and employeeID. Is that correct?

Is there reason (if it's not a business rule) that one wouldn't want to lump all employees?

Again, thanks.

Should all tables have primary keys the same length?

can an employee belong to more than one operator?

if so, then you need a third table

if not, then the PK of the employees table shouild be the employee id only, and the operator id would be a foreign key in that table

absotively not!!

Thanks again Rudy,

It's all starting to settle into my dense old brain.

Am I right in thinking that primary keys are often constituted by tuples? In forestry, a standID value would commonly reference any number of attributes (dominant species, some structural trait, management objective, etc.). Is that fairly common?

is it common to create an arbitrary key to represent a sizable number of attributes, which in their aggregate are unique, rather than making them a composite primary key?

yes

Wow, then you could run queries for semantic content using a numeric primary key. All very interesting. Thanks!