Click here to monitor SSC
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in
Home       Members    Calendar    Who's On

Add to briefcase

The One True Script Expand / Collapse
Posted Saturday, October 2, 2010 1:39 PM

Say Hey Kid

Say Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey Kid

Group: General Forum Members
Last Login: Today @ 10:55 AM
Points: 661, Visits: 2,924
Comments posted to this topic are about the item The One True Script

Best wishes,

Phil Factor
Simple Talk
Post #997241
Posted Monday, October 4, 2010 1:28 AM


Group: General Forum Members
Last Login: Thursday, October 31, 2013 3:11 AM
Points: 171, Visits: 444
Unfortunately, not only are we still forced to use one script and one Dev server, but we also have loops to jump through for the DBAs of the Test, Pre-Production and Production servers.

I would love a step by step guide to a perfect implementation strategy, but for now we just keep learning from previous mistakes and trying hard to streamline!
Post #997385
Posted Monday, October 4, 2010 10:41 AM



Group: General Forum Members
Last Login: Today @ 11:16 AM
Points: 2,527, Visits: 2,934
While I've never quite worked with anything as drastic as the "One True Script" described here, I have seen some pretty odd things, including a software company who's new client installation script for the database created the schema as it was several years ago then proceeded to apply every DDL statement written for the schema since then. Of course this meant it took hours to setup a relatively empty database for a new client.

Somewhere else as a DBA, I had a developer tell me he thought everything in the development database should be recreated from the scripts periodically. So when I asked if he was going to script all the test data that made up the development database to reapply after we reran the DDL and loaded the static/default data, he seemed to quickly drop his push to recreate everything from script.

Where I'm at now, we have several different development databases, esentially one for each project, and then an extra one which is a straight copy of production database for working with current issues and bugs. So they can code at least semi-independently. There is only 1 QA database though, and I wouldn't want to change that. Production shouldn't be the place that interactions between different changes are first seen.
Post #997709
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse