Click here to monitor SSC
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Version Numbers in DB Name?


Version Numbers in DB Name?

Author
Message
Mike-263299
Mike-263299
Valued Member
Valued Member (55 reputation)Valued Member (55 reputation)Valued Member (55 reputation)Valued Member (55 reputation)Valued Member (55 reputation)Valued Member (55 reputation)Valued Member (55 reputation)Valued Member (55 reputation)

Group: General Forum Members
Points: 55 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
Mike-263299
Mike-263299
Valued Member
Valued Member (55 reputation)Valued Member (55 reputation)Valued Member (55 reputation)Valued Member (55 reputation)Valued Member (55 reputation)Valued Member (55 reputation)Valued Member (55 reputation)Valued Member (55 reputation)

Group: General Forum Members
Points: 55 Visits: 38
Has no one heard of this before? Interesting...
Kenneth.Fisher
Kenneth.Fisher
Hall of Fame
Hall of Fame (3.8K reputation)Hall of Fame (3.8K reputation)Hall of Fame (3.8K reputation)Hall of Fame (3.8K reputation)Hall of Fame (3.8K reputation)Hall of Fame (3.8K reputation)Hall of Fame (3.8K reputation)Hall of Fame (3.8K reputation)

Group: General Forum Members
Points: 3802 Visits: 2025
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
fhanlon
fhanlon
SSCrazy
SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)

Group: General Forum Members
Points: 2401 Visits: 2276
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
Matt Miller (#4)
Matt Miller (#4)
SSCrazy Eights
SSCrazy Eights (8.6K reputation)SSCrazy Eights (8.6K reputation)SSCrazy Eights (8.6K reputation)SSCrazy Eights (8.6K reputation)SSCrazy Eights (8.6K reputation)SSCrazy Eights (8.6K reputation)SSCrazy Eights (8.6K reputation)SSCrazy Eights (8.6K reputation)

Group: General Forum Members
Points: 8581 Visits: 18282
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?
Joe Clifford
Joe Clifford
Mr or Mrs. 500
Mr or Mrs. 500 (547 reputation)Mr or Mrs. 500 (547 reputation)Mr or Mrs. 500 (547 reputation)Mr or Mrs. 500 (547 reputation)Mr or Mrs. 500 (547 reputation)Mr or Mrs. 500 (547 reputation)Mr or Mrs. 500 (547 reputation)Mr or Mrs. 500 (547 reputation)

Group: General Forum Members
Points: 547 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



Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search