Discussion Locked

naming databases when transitioning environments

0 helpful
5 replies
Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.

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

5 replies

by tony hopkinson

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.

by Former member

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.

by cartland

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

by Former member

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.

This discussion is closed to new replies.