Starting with versioning mysql schemata without overkill. Good solutions?

Question

I\'ve arrived at the point where I realise that I must start versioning my database schemata and changes. I consequently read the existing posts on SO about that topic but I

Answer 1

I do something similar to Manos except I have a 'master' file (master.sql) that I update with some regularity (once every 2 months). Then, for each change I build a version named .sql file with the changes. This way I can start off with the master.sql and add each version named .sql file until I get up to the current version and I can update clients using the version named .sql files to make things simpler.

Answer 2

i'd guess, a batch file like this should do the job (didn't try tough) ...

mysqldump --no-data -ufoo -pbar dbname > path/to/app/schema.sql
svn commit path/to/app/schema.sql

just run the batch file after changing the schema, or let a cron/scheduler do it (but i don't know ... i think, commits work if just the timestamps changed, even if the contents is the same. don't know if that would be a problem.)

Answer 3

Some months ago I searched tool for versioning MySQL schema. I found many useful tools, like Doctrine migration, RoR migration, some tools writen in Java and Python.

But no one of them was satisfied my requirements.

My requirements:

1. No requirements , exclude PHP and MySQL
2. No schema configuration files, like schema.yml in Doctrine
3. Able to read current schema from connection and create new migration script, than represent identical schema in other installations of application.

I started to write my migration tool, and today I have beta version.

Please, try it, if you have an interest in this topic. Please send me future requests and bugreports.

Source code: bitbucket.org/idler/mmp/src Overview in English: bitbucket.org/idler/mmp/wiki/Home Overview in Russian: antonoff.info/development/mysql-migration-with-php-project

Answer 4

How about versioning file generated by doing this:

mysqldump --no-data database > database.sql

Answer 5

The main ideea is to have a folder with this structure in your project base path

/__DB
—-/changesets
——–/1123
—-/data
—-/tables

Now who the whole thing works is that you have 3 folders: Tables Holds the table create query. I recommend using the naming “table_name.sql”.

Data Holds the table insert data query. I recommend using the same naming “table_name.sql”. Note: Not all tables need a data file, you would only add the ones that need this initial data on project install.

Changesets This is the main folder you will work with. This holds the change sets made to the initial structure. This holds actually folders with changesets. For example i added a folder 1123 wich will contain the modifications made in revision 1123 ( the number is from your code source control ) and may contain one or more sql files.

I like to add them grouped into tables with the naming xx_tablename.sql - the xx is a number that tells the order they need to be runned, since sometimes you need the modification runned in a certain order.

Note: When you modify a table, you also add those modifications to table and data files … since those are the file s that will be used to do a fresh install.

This is the main ideea.

for more details you could check this blog post

Answer 6

Take a look at SchemaSync. It will generate the patch and revert scripts (.sql files) needed to migrate and version your database schema over time. It's a command line utility for MySQL that is language and framework independent.