I am all for introducing control into the SQL change process, however, the method described in this article won't really help with the underlying problems of managing a large team of developers that are all making changes to a database's schema.

I have encountered many paper based, communication heavy methods such as this on previous projects and they have all failed to deliver any kind of sanity.  The people who implement these kinds of process think that merely by proscribing a method and creating a few documents will solve the issues.  Paper based processes will never work whilst development teams are under enormous pressures to deliver new functionality as the simple truth is that corners will always be cut which introduce massive holes in the delivery process and leads to utter confusion.

What is needed is a 21st century solution that uses automation to leverages the power of our machines.  Ideally the development team would be able to work with SQL like they do with other parts of the system, using a source control system. All that would then be needed is a tool that can work out what has changed in the scripts and apply those changes to a target database.

With this kind of automated approach using a version control system everything would be audited and the developers would be freed from onerous paper shuffling.  The DBAs would love it as they can audit every single change easily and at a time that is convenient to them not when a developer shoves a piece of paper in front of them.

Malcolm Leach