Question

This is probably a simple question. I have a database that I’m using to store my users details. My app queries this db to determine if they get access or not.

During testing, if I wanted to change the structure of the db, such as adding a new column, I would simply DROP the tables and re-CREATE them. I don’t think I want to do that on a live system. How would I safely go about doing something like that?

Thanks

Answer 1

Generally I’ve tracked database changes in source control as such:

• Have an initial baseline of scripts to generate the initial database. This step can be performed as needed in development and test environments, but in Production it’s pretty much just performed the first time.
• Have a folder of delta scripts. When generating a database from scratch, the scripts in this folder (sorted in a meaningful way, such as numerically or with a datetime stamp) are run after the initial baseline scripts. For this example, it would be an ALTER TABLE command in a script.

When creating a database from scratch, everything is run (in order). When applying a change to a live database, only the deltas which haven’t been run are run. (Keeping track which ones have been run is an operations procedure, by tracking which revision of source control is in which environment.)

If the folder of deltas starts to become unmanageable, I imagine you can re-baseline the create scripts from time to time. It’s probably not a bad idea just as a sanity check to make sure things haven’t been introduced into the system without being properly tracked.