How do you track your DB in source control?

[eluser]BrianDHall[/eluser]
So I finally put in a few minutes to get my latest project into source control, and it occurred to me that keeping up with differences in database schema (to say nothing of content) isn't handled with source control at all. I'd like to at least keep up with database structure in source control, though I suppose it isn't really 'source' at all.

I was thinking of just doing an export of my database structure, maybe one with just structure and one with data, and then keeping track of these files with SVN (picked SVN purely for career reasons, liked git better). Is that sensible?

How do you guys handle keeping up with your database structure and data, and ensuring it is backed up and revertable if something should go wrong? Seems silly to use such complex systems to manage source code yet fall back on tarballing for database backups.

[eluser]CroNiX[/eluser]
I do a db dump of the schema and commit it.

[eluser]Jamie Rumbelow[/eluser]
I've written a set of command-line scripts that handle database migrations for me, then I control the database schema through the migration system. Migration files consist of two functions, and 'up' and a 'down' function, which consist of their own PHP code that builds up the schema using CodeIgniter's DBForge library. That way I'm using the language and framework that I'll use to write my application to write my migrations.

It's all relatively simple; I'll write up a blog post about it and open-source the code at some point soon.

[eluser]pistolPete[/eluser]
Did you have a look at DBVersion? http://codeigniter.com/wiki/DBVersion/

[eluser]AgentPhoenix[/eluser]
I've been building a distributed system on CI now for over a year and I'm just using Database Forge to create the tables and insert the data. I have a file called fields.php that has my schema then a data.php file with all the stuff it inserts. It's worked pretty good so far.

[eluser]Colin Williams[/eluser]
We don't do dumps of our database in version control because it adds unnecessary bloat to the repository. We have nightly backups and grab them from FTP when needed

[eluser]CroNiX[/eluser]
[quote author="Colin Williams" date="1256873642"]We don't do dumps of our database in version control because it adds unnecessary bloat to the repository. We have nightly backups and grab them from FTP when needed[/quote]
Yes we do the same thing, but committing the schema isn't that large and its nice to be able to track it along with code changes via git/whatever.

[eluser]Phil Sturgeon[/eluser]
MySQL diff is pretty handy for this.

I just copy each of my changes into an UPGRADE text file and maintain 1-tables.sql, 2-default_data.sql, 3-dummy_data.sql. This is a horrible method that I need to improve.

Jamie's got a good method with mentioning DBForge. It is essentially the same as my UPGRADE plan but means you can just run an upgrade controller to do it all for the user. BambooInvoice has been doing this brilliantly for years. :-)

[eluser]n0xie[/eluser]
There should be a migrations tool for CodeIgniter but untill then dbdeploy works.

Someone feel like converting the Cake migrations implementation to CodeIgniter?

[eluser]Phil Sturgeon[/eluser]
I'll stick with tracking my SQL changes manually and logging them in a .sql file. Those solutions seem overkill (for my needs at least) and not very n00b friendly.