in reply to Re: Re: OT: Ways of managing changes to a database's structure during a project.
in thread OT: Ways of managing changes to a database's structure during a project.
After a few months of trading it turns out that discounts would be a good thing for customers spending over a certain amount. To accomodate this the database (and code) needs to be changed.
Actually, I would think that for adding such functionality you would only need to add to a DB, not actually modify the existing structure. (I dont consider table additions to be a modification.) Perhaps your tables weren't sufficiently normalized? ;-) (Code changes would for sure be required.)
Anyway, snarkyness aside, my approach with stuff like this tends to be to write a perl script that does the DB modification via SQL. I test it on copies of the production DB, and then once happy and the code is approved for production run it on the production DB. I like to use the perl script to run the SQL because I find that its usually the easiest way to ensure newly added fields have the appropriate values assigned to them. For instance, ill use alter table to add a field as nullable, walk the table updating each record so it has the correct value, then alter table again to set it not-nullable, and perhaps add an index on the new columns.
Anyway, good luck.
First they ignore you, then they laugh at you, then they fight you, then you win.