On Thu, Jul 1, 2010 at 8:08 AM, John F. Eldredge <span dir="ltr"><<a href="mailto:john@jfeldredge.com">john@jfeldredge.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">In fact, the technique of having the user select from a list of words, but actually storing the value as an arbitrary ID (generally numeric), is the recommended technique in database design.  It is called "normalizing the database".</div>
</blockquote><div><br></div><div>Umm...no.  At least, not exactly.  If a single column is independent from other columns, it is not necessary for normalization to store it as an arbitrary ID.  (For example, if you have a database table containing a driver's license number, date of birth, and hair color, you generally wouldn't store the hair color as an arbitrary ID and then have a separate table to look up the hair color.  It certainly isn't necessary for normalization.  Assuming driver's license number is your primary key, hair color is a fact about the key, the whole key, and nothing but the key.)</div>
<div><br></div><div>If you're using a crappy "DBMS" you might do this anyway, not for normalization, but for performance purposes, because the DBMS is too stupid to do it automatically behind the scenes for you.  If you're using a good DBMS, it won't be necessary, though.</div>
</div>