August 14, 2006 at 3:02 pm
I know there is another thread related to naming standards in general, but I wanted to address database naming in particular. Our company is reviewing its database naming standard which is currently something like this:
ProductsDvlp - on Development
ProductsDemo - on QA
ProductsProd - on Production
Some developers and DBAs like this strategy, while others would prefer that we use the same name on all environments. Both opinions seem to have some merit, but we are looking for outside feedback. Does anyone have any strong opinions one way or another? Thanks!
Dave
P.S. I should add that all of the environments are on seperate servers, which do not have Dvlp/Demo/Prod in the name, but do have a D/M/P to indicate the environment.
August 14, 2006 at 3:13 pm
How do you migrate SQL code from DEV->QA->PROD if the code is using 3-part naming of database objects ?
Say a stored proc is referencing a table like this:
SELECT Column FROM [ProductsDvlp].[dbo].[SomeTable]
You can't migrate the code without modifying it at the same time to change the database name, which makes source code control and code comparison a real uphill struggle. What if the person or tool doing the migration slips up and leaves references to the DEV or QA database in code that has been migrated to production ?
Same database names, different SQL Instance names is our approach.
August 15, 2006 at 9:52 am
Most shops I have been at that did development work named the databases the same. Each type of database (dev/test/qa/prod/prodfix) had it's own instance. The downside is that an inexprienced programmer could point to the wrong instance and screw things up. The solution to this one lability was to make user passwords different from production on the other environments.
RegardsRudy KomacsarSenior Database Administrator"Ave Caesar! - Morituri te salutamus."
August 15, 2006 at 10:11 am
All the above points are great.
I just want to reiterate that having fully qualified code, it is imperative to have the databases named the same, so that you have the exact code that you developed, tested, and deployed into production. this is more for code integrity (if you ever have to compare code levels between instances, you'll understand)...
How we get around the inexperienced developer/programmer is to grant differing levels of permissions to each tier, ensuring that a developer can't 'develop' above the dev instance.
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply