title: Optimize SQL databases by adding index columns
body: <p>Say I have a database looking like this;</p>
  
  <pre><code>Product with columns [ProductName] [Price] [Misc] [Etc]
  Order with columns [OrderID] [ProductName] [Quantity] [Misc] [Etc] 
  </code></pre>
  
  <p><em>ProductName is primary key of Product, of some string type and unique.</em><br>
  <em>OrderID is primary key and of some integer type, and ProductName being a foreign key.</em></p>
  
  <p>Say I change the primary key of Product to a new column of integer type ie <code>[ProductID]</code>.</p>
  
  <p>Would this reduce the database size and optimize lookups joining these two tables (and likewise operations), or are these optimizations performed automatically by <em>(most/general/main)</em> SQL database implementations?</p>
  
  <p>Technically, using (String) ProductName as primary key in <code>Product</code>, a database should be able to implement the ProductName column in <code>Order</code> as simply a pointer to a row in <code>Product</code>, and perform a <code>JOIN</code> as quicly as having an integer as a foreign key, is this a standard way of implementing SQL.</p>
  
  <p><em>Update:</em>
  This question is about how SQL servers handles foreign keys, not whether a product table needs a serial number, or how I handle to product name change in a database.</p>