I understand your intention, but no. This is not the usual approach and has the potential to bring you all sorts of pains later on the line.
Once a project is deployed, you really need 2 databases. Say your live application needs a new feature, you would want to update your "dev" site with live server's data. So ...
You pull data from live server. Hint: drush sql-sync makes it as simple as drush sql-sync @live @dev
.
You develop the feature ...
Push the code to production ... drush rsync @dev @live
or whatever you use. (Git is also great for this btw)
Now we have to update the db changes and this is where it gets funky. If you have added or altered tables and data you cannot just sync the db because you will overwrite whatever data your users have posted since you pulled. The common way to handle this is having update hooks to insert the changes in your db. Following this approach, the update hook was deployed in step #3. All that is left to do is ..
Run live.com/update.php. This will trigger your update hooks and insert changes to db.
A few things to keep in mind that make this procedure dead easy:
Drush in conjunction with drush aliases and multiple settings.php for each environnment will make transferring code and data back and forth a breeze.
Happy coding, cheers