Advantages of a lookup table with INTs over decimals in MySQL records?

Question

Trying to summarize in as few of words as possible:

I am trying to create a system that tracks the various products an individual can sell and the commission percentage they earn on that particular item. I am thinking about creating reference integers for each product called "levels" which will relate to their commission percentage in a new lookup table instead of a single reference point.. Is this overkill though or are there any benefits over just placing inline for each record?

My gut tells me there are advantages of design 1 below but not sure what they are the more I think about it. If I need to update all individuals selling product X with level Y, indexes and replaces make that easy and fast ultimately in both methods. By using design 2, I can dynamically change any "earn" to whatever percentage I can come up with (0.58988439) for a product whereas I would have to create this "level" in design 1.

Note: the product does not relate to the earn diretly (one sales rep can earn 50% for the same product another sales rep only earns 40% on).

Reference Examples:

Design 1 - two tables

table 1

ID  |  seller_id   |   product_id   |   level
-----------------------------------------------
1   |   11111      |     123A       |    2
2   |   11111      |     15J1       |    6
3   |   22222      |     123A       |    3

table 2

ID  | level |   earn
--------------------------
1   |   1   |   .60
2   |   2   |   .55
3   |   3   |   .50
4   |   4   |   .45
5   |   5   |   .40
6   |   6   |   .35

Design 2 - one table

ID  |  seller_id   |   product_id   |   earn
-----------------------------------------------
1   |   11111      |     123A       |    .55
2   |   11111      |     15J1       |    .35
3   |   22222      |     123A       |    .45

(where earn is decimal based, commission percentage)

Update 1 - 7/9/13

It should also be noted that a rep's commission level can change at any given time. For this, we have planned on simply using status, start, and end dates with ranges for eligible commission levels / earn. For example, a rep may earn a Level 2 (or 55%) from Jan 1 to Feb 1. This would be noted in both designs above. Then when finding what level or percentage a rep was earning at any given time: select * from table where (... agent information) AND start <= :date AND (end > :date or END IS NULL)

Answer 1

Does level mean anything to the business?

For instance, I could imagine a situation where the levels are the unit of management. Perhaps there is a rush for sales one quarter, and the rates for each level change. Or, is there reporting by level? In these situations is would make sense to have a separate "level" table.

Another situation would be different levels for different prices of the product -- perhaps the most you sell it for, the higher the commission. Or, the commissions could be based on thresholds, so someone who has sold enough this year suddenly gets a higher commission.

In other words, there could be lots of rules around commission that go beyond the raw percentage. In that case, a "rule" table would be a necessary part of the data model (and "levels" are a particular type of rule).

On the other hand, if you don't have any such rules and the commission is always based on the person and product, then storing the percentage in the table makes a lot of sense. It is simple and understandable. It also has good performance when accessing the percentage -- which presumably happens much more often than changing it.

Answer 2

First of all, using id values to reference a lookup table has nothing to do with normalization per se. Your design #2 shown above is just as normalized. Lots of people have this misunderstanding about normalization.

One advantage to using a lookup table (design #1) is that you can change what is earned by level 6 (for example), and by updating one row in the lookup table, you implicitly affect all rows that reference that level.

Whereas in design #2, you would have to update every row to apply the same change. Not only does this mean updating many rows (which has performance implictations), but it opens the possibility that you might not execute the correct UPDATE matching all the rows that need updating. So some rows may have the wrong value for what should be the same earning level.

Again, using a lookup table can be a good idea in many cases, it's just not correct to call it normalization.