title: Denormalize data or multiple-column key?
body: <p>I'm trying to make a judgment call in implementing a small-ish SQL Server '08 database.</p>
  
  <p>I'm translating an output text file of a flat-file database from an old COBOL system to the aforementioned SQL Server database.  It's a database of vehicle and real estate loans, which can be uniquely identified by the combination of a Lender ID (a seven-digit number), bank account number (15 digits), and "account suffix" (two digits).</p>
  
  <p>I confess I'm pretty naive when it comes to database administration (to be honest, I've not really done it up until my current position), and I'm trying to determine which of two approaches are my best option for implementing a key which will index into several other tables:</p>
  
  <p>1) Identify each loan using a three-column key of the above values, or<br>
  2) Denormalize the data by implementing a "key" column which is a 24-character string combining the three values.</p>
  
  <p>The denormalization is ugly, granted, but I can't anticipate update anomalies occurring, since loans can't be passed back and forth between banks or change their loan suffix.  A change in those values is guaranteed to be a different account.</p>
  
  <p>A compound key is more elegant, but I've read a few treatises suggesting that it's a Bad Thing.</p>
  
  <p>So, which option is likely to be a better choice, and more importantly, why?</p>