title: Benefits to Abstracting SQL Tables
body: <p>I'm going to use Drupal as my example, but it extends to other situations as well.</p>
  
  <p>I've seen database schema that are abstracted away from what a DBA would implement, most notably with Drupal. For example, When you create a Content Type in Drupal (equivalent of table), it abstracts away the fields, as new tables, in the form of <code>field_{machineName}</code>, which then relates back to the original "parent" table (<code>node_type</code> in drupal).</p>
  
  <p>When I'm dealing with MVC frameworks, like Rails, Django, or Laravel, we don't abstract away the tables, so fields are stored right on the table itself, not related back. </p>
  
  <p>What benefits do you get from implementing an abstracted table rather than a concrete table? Are there situations that this should be used, or is it generally a bad idea? It seems like a bad design choice to me, but I'm a fairly isolated programmer.</p>
  
  <p>A feeble attempt to illustrate my question, using a "Book" example.</p>
  
  <p><img src="https://i.stack.imgur.com/aw90y.png" alt="A (Poor) Illustration"></p>
  
  <p><em>EDIT</em></p>
  
  <p>I see that my diagram isn't exactly accurate. I will post a new one that reflects that <code>node_id</code> should relate to a <code>node</code> table, which then stores a reference to <code>node_type</code></p>