Version Numbers in DB Name?

  • 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

  • Has no one heard of this before? Interesting...

  • 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 FisherI was once offered a wizards hat but it got in the way of my dunce cap.--------------------------------------------------------------------------------For better, quicker answers on T-SQL questions, click on the following... http://www.sqlservercentral.com/articles/Best+Practices/61537/[/url]For better answers on performance questions, click on the following... http://www.sqlservercentral.com/articles/SQLServerCentral/66909/[/url]Link to my Blog Post --> www.SQLStudies.com[/url]

  • 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

  • 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?

  • 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

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

Viewing 7 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic. Login to reply