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).
in reply to OT: Ways of managing changes to a database's structure during a project.
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
Anyway, that was far more than I wanted to write.