Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

Version Numbers in DB Name? Expand / Collapse
Author
Message
Posted Tuesday, October 30, 2007 8:04 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Thursday, January 14, 2010 12:46 PM
Points: 51, Visits: 38
We have a group that is requesting that the database names have version numbers in the name. Something like "DatabaseName_10". Apparently part of SOA architecture would have Database_10 running at the same time as Database_15 and Database_20 where each database is supporting a different "version" of the application.

Personally, I don't like this approach because it means we'll be modifying our maintenance and mirroring to accomodate new databases and to delete old ones that aren't being used, etc. But, there may be some real need for it depending on how the systems are architected from an application perspective.

Anyone have any thoughts on this? This is just something completely new to me and any insights/thoughts are apprecited. (Even ones that tell me to get over it!"

Thanks,
Mike
Post #416527
Posted Thursday, November 1, 2007 4:09 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Thursday, January 14, 2010 12:46 PM
Points: 51, Visits: 38
Has no one heard of this before? Interesting...
Post #417446
Posted Thursday, November 1, 2007 9:29 AM


Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: 2 days ago @ 7:05 AM
Points: 3,467, Visits: 1,831
I've done plenty of versioning in databases before and generally we used Extended properties to mark which DB was which. That probably won't work for you given that you want to run multiple versions of the software at one time. One other option (and not necessarily a better one) is to create multiple instances and have each version of the DB on a different instance.

Kenneth Fisher
I strive to live in a world where a chicken can cross the road without being questioned about its motives.
--------------------------------------------------------------------------------
For better, quicker answers on T-SQL questions, click on the following...
http://www.sqlservercentral.com/articles/Best+Practices/61537/
For better answers on performance questions, click on the following...
http://www.sqlservercentral.com/articles/SQLServerCentral/66909/

Link to my Blog Post --> www.SQLStudies.com
Post #417547
Posted Thursday, November 1, 2007 2:12 PM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Yesterday @ 3:39 PM
Points: 2,185, Visits: 2,003
Is this production? I can understand having multiple versions in test (development) or UAT but I've never seen multiple versions in production. If only one of the databases is the real production while the others are older copies then maybe the older copies should be on another server.

I don't use maintenance plans so the names of the databases are unimportant from a maintenace point of view. Instead I do all maintenance via stored procs executed by SQL Agent jobs. All databases get backed up daily, databases with a recovery model of FULL get transaction log backups done. etc Databases can be added, dropped with no impact on maintenance jobs





Francis
Post #417636
Posted Thursday, November 1, 2007 2:30 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 10:30 AM
Points: 7,154, Visits: 15,647
Unless you're an Application Server Host, why would you ever need multipl versions of the same data out there?

Now - if you ARE an application server host, and you need to track what logical version of the DB you're running for a particular customer...maybe, but i'd think this is one of the uglier ways to track that info.

Sorry - I'm failing to see what value this would provide you (or anyone). That would mean that every time you increment versions, you'd have to update the version numbers. If you leave the older version online, you run the risk of "missing someone" and having them update the wrong database; if you don't then you run the risk of locking someone out for a while for no compelling reason. Never mind all of the jobs/references to that database that might need updating....

Sounds like a lot of heartache for something that could be tracked a WHOLE lot more cleanly elsewhere.


----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
Post #417645
Posted Thursday, November 1, 2007 11:07 PM
SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Monday, June 3, 2013 9:53 PM
Points: 433, Visits: 619
I can think of several instances where versioning a database as described might be useful if done carefully. For example, if you had a series of read only databases with read-only content (e.g. a catalog of specifications for parts), it might make sense then to version both the application that fronts the database and the database itself - particularly if there are major changes in the application between versions and your users were prone to being attached to older versions of the application...

Joe



Post #417739
Posted Thursday, November 1, 2007 11:42 PM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: Banned Members
Last Login: Sunday, September 7, 2014 11:11 PM
Points: 2,622, Visits: 328
Version control means managing the versions of the objects created and deployed in their SQL Server environments. Typically, this involves developers and DBAs checking scripts including object creation scripts into Visual Source Safe (VSS), or a similar version control software, when they create them and then checking them out and back in again when they make modifications.

Several benefits come with establishing version control:

Control of the versions of objects that are deployed in the various environments
Database object recovery
Change tracking -- detection of new or deleted objects
Difference tracking -- detection of what has changed in an object
History and rationale of object changes
Labeling of a version of database objects to build upgrade scripts
Simplified troubleshooting process by knowing exactly what has changed; and the ability to roll back changes to prior versions of the objects

The problem with SQL Server version control is that the tool of choice that most SQL developers and DBAs use to build their database objects is Query Analyzer. Query Analyzer does not have Visual Source Safe Integration built into it. In SQL 2005, SQL Server Management Studio is integrated with Visual Source Safe, so a developer using SQL Server Management Studio can check his objects in and out of Visual Source Safe.

Post #417755
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse