title: in general, should every table in a database have an identity field to use as a PK?
body: <p>This seems like a duplicate even as I ask it, but I searched and didn't find it. It seems like a good question for SO -- even though I'm sure I can find it on many blogs etc. out there. SO will have more of a debate than you can get on a blog. </p>
  
  <p>I'm running into an issue with a join: getting back too many records. I think of this as "expansion". I added a table to the set of joins and the number of rows expanded, way too much. Usually when this happens I add a select of all the ID fields that are involved in the join. That way it's pretty obvious where the expansion is happening and I can change the ON of the join to fix it. Except in this case, the table that I added doesn't have an ID field. To me, this is a problem. But perhaps I'm wrong. </p>
  
  <p>The question: should every table in a database have an IDENTITY field that's used as the PK? Are there any drawbacks to having an ID field in every table? What if you're reasonably sure this table will never be used in a PK/FK relationship? </p>
  
  <p>Related, but not duplicate: <a href="https://stackoverflow.com/questions/932913/when-having-an-identity-column-is-not-a-good-idea">When having an identity column is not a good idea?</a></p>
  
  <p>Apparently this debate has been <a href="http://en.wikipedia.org/wiki/Surrogate_key" rel="noreferrer">going on for a while</a>. Shoulda known. </p>
  
  <p><a href="https://stackoverflow.com/questions/63090/surrogate-vs-natural-business-keys">This post</a> (surrogate vs. natural keys) is also relevant.</p>