title: When relating two tables, should you do a composite key, or primary/foreign key separately?
body: <p>What is the industry design standard for representing the relationship between two tables? Should you use a composite key, or a primary key and foreign key separated? Are there performance differences between the two options?</p>
  
  <p><em>For example,</em> say you have a user and that user can have zero or many orders. You have the user table with attributes <code>PK UserID</code> and <code>Name</code>. An order will NEVER exist without a User.  Now, this is where the meat of my question comes in... </p>
  
  <ol>
  <li><p>Do you follow the first diagram, where a composite key is used between the <code>OrderID</code> and <code>UserID</code>?</p></li>
  <li><p>Or, do you follow the second diagram, where there is NO composite key and the Order is simply identified by an <code>OrderID</code> with a <code>FK UserID</code> to the User table?</p></li>
  </ol>
  
  <p><a href="https://i.stack.imgur.com/VJDAH.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/VJDAH.png" alt="ER Diagram"></a></p>