Table naming convention?

In our manufacturing shop, each Employee hits the time clock every time they change Jobs or Machines (work centers) during their work day.

Each record created in the Time Clock app has foreign keys that link the record to: the Employee, the Job, and the Machine which they are about to operate.

I’m trying to determine the best name for this table…

If I were tempted to call it 开发者_Go百科ClockRecords or TimeClockRecords, why wouldn’t I also consider naming it JobTimeRecords, or why not MachineTimeRecords.

Any ideas on a good name?

If you can pick a name that has actual meaning, then I think that's the best way, rather than creating some ungodly CamelCase table name base on all your foreign keys. What do the employees call it when they swap jobs? Clocking on? Switching jobs? Do they also hit the clock when they go home?

I would call it TaskSwitch or something similar, based on what the data actually means.

Punch

...as in 'punch the clock' ;) Or anything that's sort of obvious. I wouldn't use a combination of foreign keys in this case, because you're not making a simple join table, this is really a collection of 'timestamps' (but you can't call it that, alas, because now it has a special meaning), plus some foreign keys.

Relations (tables) are sets of facts, not collections of "objects". The occurrence of an employee hitting the time clock is not an "object" by any reasonable meaning of the word, hence your inclination to add the suffix "Records" in all of your candidate names.

Call it by what it represents, the event of someone hitting the clock: TimeClockHit. By the same argument, don't make your table names plural; apart from being logically incorrect, pragmatically it's a PITA to maintain a singular/plural mapping of all these names.