title: Should I use an ENUM for primary and foreign keys?
body: <p>An associate has created a schema that uses an <code>ENUM()</code> column for the primary key on a lookup table. The table turns a product code "FB" into it's name "Foo Bar".</p>
  
  <p>This primary key is then used as a foreign key elsewhere. And at the moment, the FK is also an <code>ENUM()</code>.</p>
  
  <p>I think this is not a good idea. This means that to join these two tables, we end up with four lookups. The two tables, plus the two <code>ENUM()</code>. Am I correct?</p>
  
  <p>I'd prefer to have the FKs be <code>CHAR(2)</code> to reduce the lookups. I'd also prefer that the PKs were also <code>CHAR(2)</code> to reduce it completely.</p>
  
  <p>The benefit of the <code>ENUM()</code>s is to get constraints on the values. I wish there was something like: <code>CHAR(2) ALLOW('FB', 'AB', 'CD')</code> that we could use for both the PK and FK columns.</p>
  
  <p>What is: <ol><li>Best Practice</li><li>Your preference</li></ol></p>
  
  <p>This concept is used elsewhere too. What if the <code>ENUM()</code>'s values are longer? <code>ENUM('Ding, dong, dell', 'Baa baa black sheep')</code>. Now the <code>ENUM()</code> is useful from a space point-of-view. Should I only care about this if there are several million rows using the values? In which case, the <code>ENUM()</code> saves storage space.</p>