title: Duplicate checking in SQL server - one column or many?
body: <p>In my line of work, we have to do a lot of duplicate checking on name and address data. In the past, I've always just created an index on the relevant columns and queried against those columns (firstname, lastname, address, city, state, zip, etc...) directly. Lately, I've been wondering if it makes more sense to hash those values before inserting and index only the hash for comparison. Assuming I use something like SHA-256 for the hash, I shouldn't have to worry about collisions (my data set isn't that large), and my index size would be only 32 bytes per record, or 64 bytes if I store it as a string, where as the index on NACSZ data might be 200-300 bytes.</p>
  
  <p>Is this a good idea? Am I stupid for not considering it before? Is there a valid reason not to do so? And as a matter of style, what would be a good name for this column?</p>