Re: [hackers-il] How do you version your database?
On 08/05/2011 14:50, Arik Baratz wrote:On Sat, May 7, 2011 at 8:30 PM, Amit Aronovitch <aronovitch@...> wrote:
OK for the schema, but what about the actual data?
Our script loaded the data as well :) If you start from a new database and run the script you would end up with the up-to-date schema loaded with all of the default values etc. All this was maintained by our DBA.Maybe it is not the most efficient way to do it but it worked for us.You need a script for upgrading the data, at least from each production release to the next one. And given a db-dump, you should be able to know which version it belongs to, so you know which script to run.
I think it would be best to store some date/version stamp in some table, so you'd never lose track of which schema/code is relevant for the data (once you have that, you can automate and have the upgrade-scripts use this stamp).I think what you are talking about is different - a web application or something similar that holds production data.
Right. I was thinking of SAS where the database holds the customers' valuable data.
But this is also relevant for installable software, where you want the user to have an easy way to upgrade the software without losing the data he already fed into the system and without having to manually select scripts to run according to version.
I guess if you have a backup feature that packages other stuff along with the db dump, the version info could be stored outside the dump (still it seems safer to keep the version in the db itself, to avoid dealing with file formats etc.)
What I was referring to was a product that was using a database and the programming environments that we created for that. We had no need to version live data on our database.
I see. It remains to see which case the OP had ment. :-)