http://qs321.pair.com?node_id=326471


in reply to OT: Ways of managing changes to a database's structure during a project.

I'll keep it brief, because it has nothing at all to do with Perl. For three years, I worked at a company whose product heavily relied on a database as well, and the database structure was being modified on a daily bases. (Often several times a day). Tables would be added, columns added, indices created or removed, stored procedures, triggers, views, classifications of tables (which would determine whether a table was being replicated, and whether is was replicated one-way or two-way), data removed, added, altered. You name it, it happened. (The company made a large portion of its money by implementing customer requests - hence the constant modification of the database).

We used option 2. Options 1 and 3 just take too long, and require the database to be unavailable while modifying it. Now, this is ok if apply patches to your production environment every three months - you do that in a sceduled window anyway. But in a testing environment, you can't make your testing databases unavailable for half an hour three times a day - and have 30 or 40 people unable to do their job. You want to be able to make updates on the fly.

The boundary between development and staging was a bit different. The same database modification scripts were used, and there where two staging databases, db1 and db2, both identical, and with minimal data. If a developer wanted to 'release' one or more scripts, the scripts were first applied to db1. If no errors or warnings occurred, the scripts were applied to db2 as well. However, if there was a problem applying the scripts to db1, the scripts were rejected, and a copy of db2 was loaded into db1.

Furthermore, before scripts could be taking out of staging, and into testing, I had to sign them off. Without my approval, they wouldn't make it into testing (let alone be released).

Anyway, that was far more than I wanted to write.

Abigail