Drop Table

Support Forum for database administrators and web based access to important newsgroups related to databases
Register on Database Support Forum Edit your profileCalendarFind other Database Support forum membersFrequently Asked QuestionsSearch this forum -> 
For Database admins: Free Database-related Magazines Now Free shipping to Texas


Post New Thread










Thread
Author

Database Environment Naming Production -vs- Development
I have been looking for some documentation that would support or reject
my opinion on Production -vs- Development naming conventions.  I
believe that each environment should be housed on separate servers with
identical names, access, users, stored procs.......  If you either
agree or disagree with this methodology, I would appreciate your input.

TIA,
Bill


Report this thread to moderator Post Follow-up to this message
Old Post
Bill Willyerd
04-22-05 02:23 PM


Re: Database Environment Naming Production -vs- Development
With the same access? In most situations I don't want developers to
have the same access to production as they have in development. I
pretty much never want my users to have access to development either.

Other than that, I would agree. I think that every item that you have
to change between development and production is one more item that may
get you when moving changes from development to production.

In my environments I usually have a QA or testing server as well. This
one will more closely mirror production so that moving changes from QA
to production involves no manual changes at all - everything is
automated. This helps to ensure that no unforeseen bugs get moved into
production as the result of an errant upgrade script. The upgrade
scripts are run on QA, which is identical to production at the start
(often synchronized by a backup/restore unless the data is sensitive or
too large for the QA server). If the upgrade scripts work successfully
on QA and testing the changes is successful then confidence is pretty
high that they will work correctly in production.

HTH,
-Tom.


Report this thread to moderator Post Follow-up to this message
Old Post
Thomas R. Hummel
04-22-05 02:23 PM


Re: Database Environment Naming Production -vs- Development
I agree with Thomas. You cannot / should not test on a Dev server.  So
you need at least three environments as near identical as possible.
Developers don't get access to Production except to troubleshoot a
problem that you can't repro elsewhere (unfortunately that happens).

--
David Portas
SQL Server MVP
--


Report this thread to moderator Post Follow-up to this message
Old Post
David Portas
04-22-05 02:23 PM


Re: Database Environment Naming Production -vs- Development
Thank you all for your responses.
And the access does change for Developers, we grant SELECT access to
view potential data issues and we also have Production control to move
both Databases and Interface methods (Executables and Web) from
Development to Production.  There has been a desire to create a three
tier type environment, as we cycle out Production equipment I am keeping
it for the Development environments, so in another year or so I should
have the equipment for the 'QA' level.

Thanks again,
Bill

*** Sent via Developersdex http://www.examnotes.net ***

Report this thread to moderator Post Follow-up to this message
Old Post
LilBill
04-22-05 04:23 PM


Re: Database Environment Naming Production -vs- Development
Bill Willyerd (bwillyerd@dshs.wa.gov)  writes:
> I have been looking for some documentation that would support or reject
> my opinion on Production -vs- Development naming conventions.  I
> believe that each environment should be housed on separate servers with
> identical names, access, users, stored procs.......  If you either
> agree or disagree with this methodology, I would appreciate your input.

If we were do that in our shop, we would have to have a load of servers!

More generally, it depends on what your situation is. The above could
be a good idea for in-house applications, where there is exactly one
production server. (We develop a product, and we have one development
environment and one test environment for each customer and for each
version in production, test and development. That's a lot of databases.)

I would say that the key point is that you have separate servers.
Testing on a second database on the production machine can lead
unpleasant incidents, because test reveals a query with a poor query
plan.

Wether the database should have the same name? Of course, it helps,
but what if you need more than one testing environment? One of our
customers at one point had 3-4 test databases, all for our application.
I can reveal that they did not have four test servers. Thus, it is a
good idea to make it easy to switch database in the application.

As for the same stored procedures etc, this is best achieved by having
a version-control system as the definition of your system.


--
Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp

Report this thread to moderator Post Follow-up to this message
Old Post
Erland Sommarskog
04-23-05 06:23 PM


Re: Database Environment Naming Production -vs- Development
Hi

If your servers have identical names then they can not be on the same
network!!

John

"Bill Willyerd" <bwillyerd@dshs.wa.gov> wrote in message
news:1114176300.794189.215830@g14g2000cwa.googlegroups.com...
>I have been looking for some documentation that would support or reject
> my opinion on Production -vs- Development naming conventions.  I
> believe that each environment should be housed on separate servers with
> identical names, access, users, stored procs.......  If you either
> agree or disagree with this methodology, I would appreciate your input.
>
> TIA,
> Bill
>



Report this thread to moderator Post Follow-up to this message
Old Post
John Bell
04-24-05 01:23 AM


Sponsored Links





Last Thread Next Thread
Post New Thread

Microsoft SQL Server forum archive

Show a Printable Version Email This Page to Someone! Receive updates to this thread
Microsoft SQL Server
Access database support
PostgreSQL Replication
SQL Server ODBC
FoxPro Support
PostgreSQL pgAdmin
SQL Server Clustering
MySQL ODBC
Web Applications with dBASE
SQL Server CE
MySQL++
Sybase Database Support
MS SQL Full Text Search
PostgreSQL Administration
SQL Anywhere support
DB2 UDB Database
Paradox Database Support
Filemaker Database
Berkley DB
SQL 2000/2000i database
ASE Database
Forum Jump:
All times are GMT. The time now is 05:15 AM.

 
Mobile devices forum | Database support forum archive




Copyrights DropTable.com Database Support Forum 2004 - 2006