|Keep It Simple, Stupid|
OT: Ways of managing changes to a database's structure during a project.by EvdB (Deacon)
|on Feb 04, 2004 at 10:50 UTC||Need Help??|
I am currently working on a project which is heavily database dependant. As it is a work in progress there are plenty of changes being made all the time - both to the code and to the structure of the database (ie its tables and their columns, and triggers, and indicies etc).
This would usually not be a problem as to make a change to the database I would alter the sql that creates it, drop the database, recreate it, load up the test data and continue work. This is good and dandy, however...
The project is about to go live (web-based shop) and my problem is that on the live system data will need to be kept over the changes.
My problem is how to go about making these changes to the database structure whilst making it possible to apply them to a production system. I have come up with the following possible methods but would like some feed back on them before commiting to one.
There are benefits and problems to each one. All of them would require keeping track of which version of the structure is currently being used and then acting accordingly.
As I see it this is a general database based project problem but I have not seen much discussion on it here or elsewhere (please correct if wrong). For the record I am using Postgres 7.4.
I am personally tending towards using sql commands which are stored in files named something like 'alter-2.3-2.4.sql' which would change the database from version 2.3 to 2.4.
Another consideration: How can all this be tested?
--tidiness is the memory loss of environmental mnemonics