SQLServerCentral Editorial

The One True Script

,

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.

Rate

You rated this post out of 5. Change rating

Share

Share

Rate

You rated this post out of 5. Change rating