You really wouldn't store colors in a separate table -- I'll give you a more relevant and real-world example.
You have a database of companies. Lots of people work at each company. In fact, many companies are subsidiaries of other companies, but I'll keep this example simple.
We'll create two tables, company and employee. Whenever you create a table, always create a unique identifier. SQL provides a means to do this -- you create a column that is a primary key (has to be unique), that is auto-incremented. This means that whenever you create a new row (aka record), SQL will automatically create a key for that row. It also makes it easier to relate one table's rows to another table, as you'll see. There are exceptions to this rule, but 99% of the time, you want to create that key field. Most people call the field "id."
Here are the tables:
company
id (primary key, auto incremented)
name
address
city
state
zip
naics (this is similar to the old SIC codes)
etc...
employee
id (primary key, auto incremented)
company_id (this is the key to linking to the company table)
firstname
lastname
age
height
favcolor
etc...
Now, when you create a new employee, one of the things you select is the company she works for. This will put a number in the company_id field, which relates her to the appropriate company information. Now, if you wanted to send her a letter (and you know she is employee #15), just do this:
SELECT address, city, state, zip FROM company, employee
ON company.id = employee.company_id WHERE employee.id = '15'
I'm pretty sure that's right -- if we ask nicely, I'm sure a more qualified SQL expert will correct my code if I'm not exactly right. However, that is the general idea when attempting to link two tables.
Does that help?
