zend database migration scripts

I would like to know how do you guys work in Zend Framework environment especially how to keep the database table up to date with others team (database change management) . I ha开发者_如何学Gove small team who works at their home and we need to have latest database table everytime. We works at home so sometimes we work after finishing our main job at office.

Any idea ?

ps: just like Rails migration

We're using the db deploy feature of phing to keep track on database changes over time and to update the database between our developers. We're also using it to deploy new versions of our application, which usually include database updates.

Basically each time someone need to update the database scheme, he adds a database migration script. Each developer can then run phing to execute these db migration scripts automatically.

For more details, see a good guide on the subject here: http://www.davedevelopment.co.uk/2008/04/14/how-to-simple-database-migrations-with-phing-and-dbdeploy/

There is also a ZF-specific migration tool developed by Rob Allen (@akrabat):

Akrabat_Db_Schema_Manager: Zend Framework database migrations

In principle, it is similar to the dbdeploy tool in Phing. In Rob's Schema Manager, each delta file contains a class with methods up() and down() that perform, respectively, the upgrade and the downgrade of the db schema.

It comes with a command-line tool built on Zend_Tool that can perform specific migrations, report the current schema version, etc.

Update (as suggested by @markus-tharkun)

I have created a db migration tool, based on on Rob's original work, that uses vanilla PDO rather than Zend_Db. The tool is called "South For the Winter" and the owner (Diamond Web Services / StartupDevs) has released the code on Github: https://github.com/startupdevs/sftw

I saw Harrie Verveer give a really interesting talk about this subject at PHPNW last year. It's summarised here:

http://techportal.inviqa.com/2011/01/11/database-version-control/

The main conclusion he comes to is that there currently is no silver bullet for this problem.

I have seen the patch system get horribly out of control on large projects but work perfectly on smaller ones. The method you choose will largely be down to the size of the team, the size of the project and the frequency of db changes. It's a problem that is easy to over-engineer on smaller projects so be mindful of how much work you put into the solution.