SQL Clone
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in

The One True Script

By Phil Factor,

To operate in any successful database-development team, there is a lot of negotiation and compromise involved.

I once worked with a developer who had been taught database development in a particular way, in an intensive course when he left the army. He regarded any deviation from this method as being sacrilege. He was taught to develop a database from a single source script, complete with all the comments and documentation.  Vainly, I remonstrated with him. How could a team work in this way? He looked pained; I was his team leader, but I felt I couldn’t insist. We had to fall back on a compromise.  Only one person could checkout the True Source at any one time.  Everyone else would have to wait for check-in to add their work, in turn, to the script by some sort of semi-automated merge.

Although the One True Script was liberally commented, including tables and columns, in ways that most of us can only dream of, the compromise would fail occasionally. We were working on one development database with realistic quantities of test data. Disks weren’t so cheap in those days.  The developer with the One True Script would highlight the code he, or she, wished to execute in order to make changes. Occasionally, my ex-army friend would accidentally hit 'execute' with nothing selected. Instantly, the database would be destroyed, as every table was rebuilt, and all the unsaved changes made by the team, except for the holder of the One True Script, would be reverted. We'd have to wait whilst the data was BCPd back in from file. Although we all learned survival tricks such as saving everything as a script on every change, using headers in routines, trying things out within transactions, designating different development areas, and never using 'SELECT *' in code, I never felt it worked.

Mercifully such days are gone. We have schemas. We can have database source control within SSMS. We can enjoy continuous integration. Or is team-based database development work still fraught with problems? Are developers still forced to share the same dev server just to make things happen properly?  Is the voyage of database development always smooth sailing now?

Phil Factor.

Total article views: 220 | Views in the last 30 days: 1
Related Articles

Working with multiple Database change Release.

Latest database change script release should check for previous database change too


Script to change auto growth settings for all databases in SQL Server

Script to change auto growth settings for all databases in SQL Server.


Development and Production Database

Insert Into Development and Production Database at the same time


Is Rollback Feasible for Database Changes?

Many of us would like to be sure we could rollback changes made during a deployment if they caused i...


Continuous Integration in a Development Environment using Red Gate Backup and SQL Compare

My co-worker and fellow DBA, Leigh Freijo has a blog entry about a Powershell script he created to r...