We create source code at development server and push the changes to production. It's really easy to keep synchronized all our code. But with databases it's different. [...] It's a recurrent problem working with databases. We create database objects (tables, views, ..) in the development server and when our application is ready to go live we push the changes to production server. If we are smart developers we save all database scripts in a file and when we deploy them to production we execute the script.

He mentions tools like dbdeploy and phing to help make these migrations a bit more automatic. He needed something a little different though - a command-line script that would, based on an ini file, sync two or more databases. He's created the basic script that includes the actions to show the differences between the databases, a summary of the differences and an execution method to bring them into sync. He gives a basic example of how it would handle the sync between his example production and development databases.

If you want to tell me I'm crazy, you can post it in a comment here, it makes me happy. I had some reasons to dislike bind9 which finally made me write my own DNS daemon, and I'll explain that here. My need was to have a stable dynamic DNS server working in most environments, with an easy to configure master/slave relationship (with realtime synchronization), and a way to change records instantly from PHP...

Rather than using the (slightly unstable) dlz technology to pull the information from a MySQL database, he opted to roll his own that includes support for:

• RFC 1035 standards
• realtime data update
• slave/master relationship (with a keepalive connection)

Want to try it out for yourself? Drop him a line and ask about it!

He's also run some statistics on the performance of the daemon as compared to the standard BIND installation and come up with some instructions on how you can install and configure your own instance.

One of the most common tasks that we experience as web developers is synchronizing a development web server with a live site. There are many solutions that have been tried before. [...] However, every single method (described above) has the potential for immediate and catastrophic failure, even with a backup.

He suggests the use of the PEAR installer functionality along with version control to easily deploy a site, allowing for things file dependencies and versioning. So, if files are handled through that package, how is the database managed? Through another PEAR-related feature - the post-install database initialization the Installer makes possible. Check out Greg's post for the full details on how to get you and your site started.