Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
evjo
Starting Member
20 Posts |
 Posted - 2006-11-29 : 00:31:56
|
| Hi,Every month we publish a new database to our staging / test server and we have to store this months & last months versions of the database on the same server for comparison testing. One of the developers would prefer to name the databases with "DBNAME_YEAR_MONTH", can anyone see anything majorly wrong with a continuously changing database name? The alternative is to have DBNAME (this months) & DBNAME_OLD (last months), this was the name stays the same for the current month. Which is the better solution? |
|
|
snSQL
Master Smack Fu Yak Hacker
1837 Posts |
Posted - 2006-11-29 : 00:37:35
|
| It shouldn't be a problem as long as you don't have code that uses three part names, but then you'd be having problems with them already. |
 |
|
|
Westley
Posting Yak Master
229 Posts |
Posted - 2006-11-29 : 05:00:49
|
| No problem with the naming, but the developer might have issue with their scripts, where every month, they will need to change their scripts to point to the new DB name. If its all set in some kind of a control file, then its ok, if its hard coded, then it will be fun to change it every month :) |
|
|
|
Kristen
Test
22859 Posts |
Posted - 2006-11-29 : 09:20:41
|
| Tough call. DBNAME_CURRENT and DBNAME_OLD have the benefit of scripts being easy to set up. But runs the risk of the names being changed when people aren't expecting it, and them getting wrong-footed.We have DBNAME_DEV, DBNAME_QA, DBNAME_TEST and DBNAME_LIVE.We publish "upgrades" and apply them to QA. We then run our tests on QA an compare them against stored results (NOT against a stored copy of the database, which will have changed, plus Create Dates for records created as part of our test will be [legitimately] different, and so on).If the QA goes OK we copy the LIVE database to TEST, apply the changes to TEST, do some "real world" testing to make sure that the deployment is sound on the Live database, and then if that goes well we apply the changes to LIVE.(Our QA test involves running automated scripts on the Front End and taking a screen capture image which is compared against a "known good" master version. Images which are different are stored, and then a few simple web pages listing the outcome of the tests enables the images to be compared easily [and copied to the Master if they are valid improvements, so that they become the Master for subsequent tests])Kristen |
|
|
|
|
|
|
|
|
DB Naming with Version