I have a table for storing coupons/discounts, and I want to use the coupon_code column as the primary key, which is a VARCHAR
.
My rationale is that, each coupon will have a unique code, and the only commands I will be running are SELECT ... FROM ... WHERE coupon_code='..'
I won't be doing any joins or indexing, and I don't see there ever being more than a few hundred entries in this table.
It seems to me that this will be OK, but I don't know if there is anything I'm missing/not thinking about.
Of course you can, in the sense that your RDBMS will let you do it. The answer to a question of whether or not you should do it is different, though: in most situations, values that have a meaning outside your database system should not be chosen to be a primary key.
If you know that the value is unique in the system that you are modeling, it is appropriate to add a unique index or a unique constraint to your table. However, your primary key should generally be some "meaningless" value, such as an auto-incremented number or a GUID.
The rationale for this is simple: data entry errors and infrequent changes to things that appear non-changeable do happen. They become much harder to fix on values which are used as primary keys.