ratbastid

Unless you have very standard labor rates, and only a few of them, it might not make a lot of sense to normalize this data into two tables. Based on the data you showed there, you'd have six LABOR_RATE records and nine WORK_ORDER records. Probably doesn't get you all that much to abstract your labor rates into their own table. I'd probably suck it up and duplicate a little data, especially if this was a frequent query.

However, how you'd do this is, you'd add an "ID" field to the LABOR_RATE table (probably an auto-incrementing integer) and assign that as PRIMARY KEY. Then you'd add a RATE_ID field to WORK_ORDER, and in each WORK_ORDER record, put the ID of the appropriate LABOR_RATE field.

Then, once you've got data in both tables to actually relate them, you join them with the SQL command:

SELECT * FROM WORK_ORDER, LABOR_RATE WHERE LABOR_RATE.ID = WORK_ORDER.RATE_ID;

You can list specific fields you want out of it by saying "SELECT WORK_ORDER.WO_ID, RATE.Rate FROM..."

I'm guessing you intend to use Effective_Date as the primary key on LABOR_RATE, which would probably work, though it's a better practice to use a key that is ONLY the key and doesn't actually carry any data meaning. It would be easy to just up and alter that value in one table or the other because the value changes, and that leaves you with data syncronization problems.

Incidentally, the classic naming convention for tables and fields is to have tables be First Capped and fields be lower case. SQL commands are traditionally typed all upper case, so it's easy to see what's what in a SQL statement:

SELECT * FROM Work_Order, Labor_Rate WHERE Labor_Rate.id = Work_Order.rate_id;