title: Why use database migrations instead of a version controlled schema
body: <p>Migrations are undoubtedly better than just firing up phpMyAdmin and changing the schema willy-nilly (as I did during my php days), but after using them for awhile, I think they're fatally flawed.</p>
  
  <p><strong>Version control is a solved problem.</strong> The main function of migrations is to keep a history of changes to your database. But storing a different file for each change is a clumsy way to track them. You don't create a new version of <code>post.rb</code> (or a file representing the delta) when you want to add a new <em>virtual</em> attribute -- why should you create a new migration when you want to add a new non-virtual attribute?</p>
  
  <p>Put another way, just as you check <code>post.rb</code> into version control, why not check schema.rb into version control and make the changes to the file directly?</p>
  
  <p>This is functionally the same as keeping a file for each delta, but it's much easier to work with. My mental model is "I want table X to have such and such columns (or really, I want model X to have such and such properties)" -- why should you have to infer from this how to get there from the existing schema; just open up <code>schema.rb</code> and give table X the right columns!</p>
  
  <p>But even the idea that classes wrap tables is an implementation detail! Why can't I just open up <code>post.rb</code> and say:</p>
  
  <pre><code> Class Post
      t.string :title
      t.text :body
   end
  </code></pre>
  
  <p>If you went with a model like this, you'd have to make a decision about what to do with existing data. But even then, migrations are overkill -- when you migrate data, you're going to lose fidelity when you use a migration's <code>down</code> method.</p>
  
  <p>Anyway, my question is, <strong>even if you can't think of a better way, aren't migrations kind of gross?</strong></p>