title: Primary key/foreign Key naming convention
body: <p>In our dev group we have a raging debate regarding the naming convention for Primary and Foreign Keys.  There's basically two schools of thought in our group:</p>
  
  <p>1:  </p>
  
  <pre><code>Primary Table (Employee)   
  Primary Key is called ID
  
  Foreign table (Event)  
  Foreign key is called EmployeeID
  </code></pre>
  
  <p>or</p>
  
  <p>2:  </p>
  
  <pre><code>Primary Table (Employee)  
  Primary Key is called EmployeeID
  
  Foreign table (Event)  
  Foreign key is called EmployeeID
  </code></pre>
  
  <p>I prefer not to duplicate the name of the table in any of the columns (So I prefer option 1 above). Conceptually, it is consistent with a lot of the recommended practices in other languages, where you don't use the name of the object in its property names. I think that naming the foreign key <code>EmployeeID</code> (or <code>Employee_ID</code> might be better) tells the reader that it is the <code>ID</code> column of the <code>Employee</code> Table.  </p>
  
  <p>Some others prefer option 2 where you name the primary key prefixed with the table name so that the column name is the same throughout the database.  I see that point, but you now can not visually distinguish a primary key from a foreign key.  </p>
  
  <p>Also, I think it's redundant to have the table name in the column name, because if you think of the table as an entity and a column as a property or attribute of that entity, you think of it as the ID attribute of the <code>Employee</code>, not the <code>EmployeeID</code> attribute of an employee. I don't go an ask my coworker what his <code>PersonAge</code> or <code>PersonGender</code> is. I ask him what his Age is.</p>
  
  <p>So like I said, it's a raging debate and we go on and on and on about it.  I'm interested to get some new perspectives.</p>