You shouldn't need to keep your staging and production databases in sync when it comes to variable data such as customers, orders etc.
Instead, you should have a dev-stripped database (no logs, customers, orders etc) from production which you use in staging. You can place all the test orders you want to re-populate that data. This also means you don't have the risk of emailing live customers from your staging database.
In terms if updating your database, design etc, you need to track two areas of change:
- Configuration changes (database)
For file changes, you should be using a version control system (Git, Subversion, etc) and tracking your changes as you make them. When they're tested and ready to deploy to production, then you can merge them into master.
For database changes, the only way you can really ensure that when you deploy your code to production that everything just switches over is if you use Magento setup/upgrade scripts to add your configuration to the database. If you haven't used them before, they're basically a PHP file and a version number in your config.xml for a module that you bump up, add a new install script and tell it what you want to change, whether that be creating new tables or data, saving or changing configuration values, etc.
The major benefits of tracking all your configuration changes in installer scripts (I mean all of it, literally), is:
- When you deploy your source code and reindex, Magento will update your production database with all the new configuration it needs
- You don't have to worry about managing database changes separately
- It's all versioned - each module version increment can have a new install script, so you can see what's changed in the module over time.
For more information, Alan Storm has a great article on them.