ModestyBlaise84 (4/26/2011)
In my opinion, adding a trigger to the production database; creating a table in production database, dropping a table from production database, creating a job in production database - IS RELEASE.Every change made in the production database should be considered as a release.
For example, adding a trigger could affect performances and should be planned ahead, tested, released, monitored. Same with the other changes which makes these steps actually:
Release I, Release II and Release III
Where does FKs fit in? (Their name has to be unique on the database level)
What happens in case of the replication, if changed table is published?
How this data transfer affects tlog and backup size?
What happens in case there is a log shipping set up on the database? How is space affected? How are performances affected?
Depending on the table structure and the way transfer is done, indexes can end up heavily fragmented if created before table is populated.
Although being useful in some cases, it seems to me that this approach has limited usage and hidden risks which should have been mentioned as well.
I agree with you except your conclusion.
Of course you need to plan and test everything before you apply to a production database. That includes the steps to release itself (even when done in a single step, not doing so places a ridiculous amount of faith in the release-script(s)). That doesn't diminish the usefulness of this approach at all (especially if it can get your user's experience up thousand-fold by minimizing actual downtime).