title: Database version control plan: hot or not?
body: <p>Based on reading around the web, stack overflow, and mostly <a href="http://odetocode.com/blogs/scott/archive/2008/02/03/versioning-databases-branching-and-merging.aspx" rel="nofollow">these articles</a> about db versioning that were linked from coding horror, I've made a stab at writing a plan for versioning the database of an 8 year old php mysql website.</p>
  
  <pre><code>Database Version Control plan
  - Create a db as the "Master Database"
  - Create a table db_version (id, script_name, version_number, author, comment, date_ran)   
  - Create baseline script for schema+core data that creates this db from scratch, run this on Master Db
  - Create a "test data" script to load any db with working data
  - Modifications to the master db are ONLY to be made through the db versioning process
  - Ensure everyone developing against the Master Db has a local db created by the baseline script
  - Procedures for commiting and updating from the Master Db
      - Master Db Commit
          - Perform a schema diff between your local db and the master db
          - Perform a data diff on core data between your local db and master db
          - If there are changes in either or both cases, combine these changes into an update script
          - Collect the data to be added to a new row in db_version table, and add an insert for this into the script
              - new version number = latest master db version number +1
              - author
              - comment
          - The script must be named as changeScript_V.sql where V is the latest master db version +1
          - Run the script against the master db
          - If the script executed succesfully, add it to the svn repository
          - Add the new db_version record to your local db_version table      
      - Update from Master Db
          - Update your local svn checkout to have all the latest change scripts available
          - compares your local db_version table to the master db_version table to determine which change scripts to run
          - Run the required change scripts in order against your local db, which will also update your local db_version table
  </code></pre>
  
  <p>My first question is, does this sound correct?<br>
  My second question is, the commit process seems a bit complicated to do more than once a day.  Is there a way to reliably automate it? Or should I not be commiting database changes often enough for it to matter?</p>