I think that about covers it for processes that are likely to deliver any real benefits.

Of course there are always many other "processes" that people employ such as in one of the other posts whereby the production database is detached, zipped and emailed to the developers for them to apply changes however they want and is then emailed back to the production DBA to re-attach.  Laughable, of course but it shows that people can think they have a "process" when, instead they have a disaster waiting to happen.

The first scenario, as you quite rightly point out, suffers from a lack of scalability if the database changes are complex and/or there are more than a few people making changes as there is an exponential increase in effort as changes/people increases linearly.  This is the problem that all pure "diff tools" suffer from.

Only the last two scenarios offer a solid approach to change management - one thing I didn't see (maybe it's there and I missed it) was that there should be a automated, continuous database build implemented from the source control system with a direct feedback loop (via email) to the development team.  That way, when changes are checked in developers get notified almost immediately that there are problems and so can fix them very quickly instead of issues coming out when the next daily or scheduled build occurs when memories have faded somewhat.

The last two approaches are what DB Ghost (http://www.dbghost.com) has been doing since 2003 and, in fact, our whitepaper on the challenges of database change management has been out there for about 3 years so I'm glad that Microsoft (with VSTS4DB) and Red Gate have finally validated what we have been stating all this time - that solid change management can only be achieved by using that most valuable piece of software - the source control system.

Welcome to the party guys, I'm just surprised you didn't do it sooner