I am a proponent of the manual scripts method (with some automation ).

Most of the drawbacks listed by the author can be summarised as "its a big hassle for the DBA". This is true in many situations, especially for some table and index changes and I am interested in seeing part 2.

For the bulk of development which is stored procs, views, functions and new tables, I use a hierarchical directory of folders sorted in the order that scripts must be applied and have a script called RunSQL which runs all the scripts.

With reference data, my RunSql script can read text files in comma delimited form and these are kept in VSS.

therefore you cannot say who updated what code and when with a complete history of all changes...

making the change is not change management.

Good layout of the common solutions.  We currently use the manual approach wioth templates for stored procs and triggers. This was working until we grew to about 12 developers.  Now it has become a mess since everyone is at different levels of sql scripting and some better then others.  We are currently looking for a new solution and are evaluating DB Ghost as a possible solution.  Any one use or heard anything about it?

Can't wait for part 2!

Jim

This looks like it's going to be a very good series of articles.  I'm always looking for ways to improve how we manage database change.  We are a small team, with myself (DBA and actually lead developer too), and 2 other developers.  We maintain 3 separate environments (Development, Beta and Production). 

Currently I am the only person responsible for any database changes - schema, stored procedures  and permissions.  I've implemented a fairly manual approach, but I use Visual Studio.NET with a database project to manage "groups" of changes.  VS.NET also will do some automatic scripting of schema changes, but you are on your own as far as stored procedure change scripts are concerned.  The drawback is that all "rollout" status of each DB project, as well as any interdependency between projects (project B requires project A be rolled out first) is all completely manual, and I track it all in an Excel spreadsheet for now.

This system is effective for our needs now, but as the team grows, I'm sure we will need to make some changes.