So, let's version control MySQL. Any ideas?

Things that go in version control:
* Table/View Creation Scripts
* Index/Constraint Creation Scripts
* Stored Procedures Creation Scripts
* "Seed Scripts" (scripts that populate your tables with the base data for your program/site to work)
* Other maintenance adhoc scripts like creating backups and moving data from Prod, Cert, Dev
* SQL Unit Tests

Things that don't belong in Version Control:
* The populated table itself, that is called a "backup" and should go elsewhere

I only store scripts as creates, I don't store update scripts, that way if I need to recreate something I can run all the creates. If I need to check to see if a db is the latest I gen a create and diff it with the create in source control. (Which can be part of your build process if you want)

@bkwilliams fair enough. How do you deal with parts of the Dev that go into the database? E.g.: a platform that uses a block manager and said blocks configuration are stored in the database.

@Bahbel that's covered underneath the seed data section; anything that's not part of the database structure itself but is needed by the application

@Bahbel There is a major assumption here that Developers are your DBAs if you have split rolls then development would only store what they need to run the application and the DBAs would handle their items outside version control

If your ORM support migrations, use them! Use DB seeding/fixtures for default data.

Migrations!

Migrations!

Hey guys. Thanks for the recommendations. I've googled a bit and got to phinx which seems good to onboard on my platform. Am I on the right path, or are there better recommendations?