Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
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: 217 | Views in the last 30 days: 2
 
Related Articles
FORUM

Working with multiple Database change Release.

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

SCRIPT

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

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

FORUM

Development and Production Database

Insert Into Development and Production Database at the same time

BLOG

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...

ARTICLE

Three Rules for Database Development

Today Steve Jones talks about a series of rules he found for database development.

Tags
 
Contribute

Join the most active online SQL Server Community

SQL knowledge, delivered daily, free:

Email address:  

You make SSC a better place

As a member of SQLServerCentral, you get free access to loads of fresh content: thousands of articles and SQL scripts, a library of free eBooks, a weekly database news roundup, a great Q & A platform… And it’s our huge, buzzing community of SQL Server Professionals that makes it such a success.

Join us!

Steve Jones
Editor, SQLServerCentral.com

Already a member? Jump in:

Email address:   Password:   Remember me: Forgotten your password?
Steve Jones