title: What is the best or most accepted way to store a custom value for a field that is generally relational to a table of possible values?
body: <p>In my application each of my users is required to select a suburb to which to associate their profile. The <code>users</code> table has a field <code>suburb_id</code> and a table called <code>suburbs</code> has both an <code>id</code> and <code>name</code> field.</p>
  
  <p>Our <code>suburbs</code> table contains most of the suburbs that we will need, however occasionally users will need to enter suburbs that we don't have in our table, or have popped up since we populated our table.</p>
  
  <p>What is the best way in terms of database design to solve this problem.</p>
  
  <p>I had considered changing the field <code>suburb_id</code> to just <code>suburb</code> and then testing in the application whether it was an integer or a string - if it was an integer the application would assume it is related to an item in the <code>suburbs</code> table, if it was a string it would assume otherwise. However, if a user was to simply enter an integer in the <code>suburb</code> field then the application would obviously mistake it and try to match it up with a value in the table.</p>
  
  <p>Is that an acceptable way to deal with the problem (it seems gimmicky to me - I am sure there must be a better solution).</p>
  
  <p>EDIT: I would also like to avoid inserting data provided from users into the <code>suburbs</code> table (even if flagged) as I don't want to affect the quality of the suburbs data we have.</p>