General discussion

Locked

naming databases when transitioning environments

By cartland ·
There is plenty of debate on naming standards that I've read, none of which address a question I have on the database name itself.

I know a number of sites that like to incorporate the environment (eg. DEV, TEST, PROD) into the database name so 'mydb' becomes 'mydb_DEV', etc.

A number of developers but mainly DBAs seem to like this.

In many issues there are pros & cons, however, I cannot see any merit in this. It is a significant hassle where cross-db references are used in stored procs and in maintenance scripting where database names cannot be aliased (easily anyway - I use SQLServer)

I was interested in feedback on this.

thanks

This conversation is currently closed to new comments.

5 total posts (Page 1 of 1)  
| Thread display: Collapse - | Expand +

All Comments

Collapse -

The reason DBA's

by Tony Hopkinson In reply to naming databases when tra ...

like it is illustrated by a simple example.
A DBA purged the production database instead of the test one, during a transition period where there were no backups going. Multi-national telecoms firm. I'm not saying he would have definitely realised he was ending his career if it had a different name but ...

I'd put the effort into the aliasing rather than trying to remember which DB you are in personally.

I used to build up the sql in varchars and then use execute.

Collapse -

I don't like it

by CgMcCarthy In reply to The reason DBA's

Putting Dev or QA in the name is required if the QA/Dev envir. is in the same place as the Prod. As I see it, if you have Prod & Dev on the same server, you will have issues.

This convention is carried down from the "big iron" days when everything was on one server and you didn't have a choice.

I have a separate domain (not connected) for testing & development. Before that, I had different servers. In my case, the server or domain tell me where I am.

You need to limit the changes you have to make to put something in production and having to manually re-name a database is not a good thing.

Collapse -

sympathetic but ..

by cartland In reply to I don't like it

While I appreciate DBAs wanting to lower their risk, like CgMcCarthy, I don't agree that they should shift that risk to the development side and increase overall effort at the same time.

And yes it's amazing the number of developers who want to runup multiple instances of a db on the same machine (their machine say) who don't realise they can easily run multiple instances of sqlserver on that same machine and host the dbs in each instance.

Anyway I seem to have persuaded my current site to this view for the moment.

thanks for the replies

Collapse -

I think you mis-understand

by CgMcCarthy In reply to sympathetic but ..

I don't use Dev or Prod or QA in my database names (or anything else if I can help it).

It depends on what I'm delevoping or maintaining. I prefer to use a different network (domain) to test/develop, that way I can keep the same server & database names that I have in production.

Today you can use VM Ware (or MS Virtual Server) to create a virtual network complete with servers & databases on a single workstation (providing you have a powerful enough workstation) that is completely disconnected from you production network.

Collapse -

I agree

by cartland In reply to I think you mis-understan ...

sorry - my previous reply wasn't sufficiently clear. I agree with you 100%.

regards

Back to Software Forum
5 total posts (Page 1 of 1)  

Related Discussions

Related Forums