MySQL - Optimizing column referencing?

I'm having difficulty trying to form the actual question I have, so hopefully I can get the point across with visual aid.

What I'm wondering is whether or not my current database design is horribly flawed, slightly inefficient, or ... correct.

Q: Is there a better way for a row cell to reference a column in another table, aside from just saving a string of that column's name?

Example: There are two tables.

table01: has 3 columns - c_id, customer, tier (tier holds the column name of a tier in table02 )

table02: has 5 columns - i_id, item, tier1, tier2, tier3

table01 +------+----------+------+
        |'c_id'|'customer'|'tier'|
        +------+----------+------+
        |   1  | John     | tier1|
        |   2  | Lisa     | tier2|
        |   3  | Mike     | tier1|
        |   4  | Tom      | tier3|
        +------+----------+------+

table02 +------+------+-------+-------+-------+
        |'i_id'|'item'|'tier1'|'tier2'|'tier3'|
        +------+------+-------+-------+-------+
        |   1  | apple| $1.99 | $2.99 | $3.99 |
        |   2  | chalk| $2.99 | $3.99 | $4.99 |
        |   3  | pens | $3.99 | $4.99 | $5.99 |
        |   4  | shirt| $4.99 | $5.99 | $6.99 |
        +------+------+-------+-------+-------+

Result:

John    +------+-------+
        |开发者_JAVA技巧 apple| $1.99 |
        | chalk| $2.99 |
        | pens | $3.99 |
        | shirt| $4.99 |
        +------+-------+

Selecting John's row would yield tier1, which is then used to query for table02.tier1, and grab that column's contents. (In this discounted prices for tier1 customers). The tier1 items would then be displayed with their correct prices.

Is there a more efficient way to reference an outside table's column name, like... in the style of foreign keys? Where if the column name changes, then that information waterfalls to other linked data cells? Is my approach correct, or should I restructure how I'm doing things?

---

It isn't completely clear how the c_id and i_id columns are supposed to be used, but a more conventional design would be to use a design like this:

table01 +------+----------+------+
        |'c_id'|'customer'|'tier'|
        +------+----------+------+
        |   1  | John     |  1   |
        |   2  | Lisa     |  2   |
        |   3  | Mike     |  1   |
        |   4  | Tom      |  3   |
        +------+----------+------+

table02 +------+------+-------+
        |'i_id'|'tier'|'cost' |
        +------+------+-------+
        |   1  |   1  | $1.99 |
        |   2  |   1  | $2.99 |
        |   3  |   1  | $3.99 |
        |   4  |   1  | $4.99 |
        |   1  |   2  | $2.99 |
        |   2  |   2  | $3.99 |
        |   3  |   2  | $4.99 |
        |   4  |   2  | $5.99 |
        |   1  |   3  | $3.99 |
        |   2  |   3  | $4.99 |
        |   3  |   3  | $5.99 |
        |   4  |   3  | $6.99 |
        +------+------+-------+

---

I edited the example to better exemplify my thoughts. Which really doesn't change your answer much. So it'd be better to consolidate the tier columns into one column and just repeat the item id (i_id) data several times? My reasoning behind breaking the tier/cost structure into columns was to cut down on redundancy. Would that approach require me to make a new table to index the tiers for foreign keys?

I understand what you're doing now. Somewhere along the line, you might have a 'Sales' table which records a c_id, and i_id, a quantity, a date and other such information (if each sale consists of one item; otherwise, you'd have an 'Orders' table and an 'OrderItems', and the c_id would be associated with the orders table and the i_id would be associated with order items, and there'd be an order number to connect the two tables).

If you add your item desciption to the revised table02 above, you would be violating 3NF. You should have a table such as 'Products' with the i_id and item columns. This would give names to item numbers. The table02 (maybe 'TieredItemCosts') table I proposed would remain as it is; the primary key is the combination of (i_id, tier).