The Importance of Consistent Server Setup

  • Comments posted to this topic are about the item The Importance of Consistent Server Setup

  • Hi Ben,

    When I see code that hard-code a database name, I shudder. It must be really old code, because today I prefer to create an abstraction layer, ie. a view that references that table in the other database.
    Then I have a sproc that re-creates all those views, whenever the database name changes.

    I agree that it is a good idea to have similar environments, so that dev., test and production servers look and feel the same.

    Best regards
    Henrik

  • We run parallel, but not identical names for the databases, servers and tables
    company_Prod_Price_List
    company_Dev_Price_list

    Helps keep people straight as to where they're working and avoids accidently running a script on the wrong db.

    ...

    -- FORTRAN manual for Xerox Computers --

  • Different clients have different setups. But one for which I do the most development set up a very consistent Dev and Prod environment and it makes things so much easier.  At the last place I was an employee, we had a very consistent setup for DEV, TEST, and PROD.  Again made things so much easier.

  • jay-h - Friday, October 12, 2018 7:23 AM

    We run parallel, but not identical names for the databases, servers and tables
    company_Prod_Price_List
    company_Dev_Price_list

    Helps keep people straight as to where they're working and avoids accidently running a script on the wrong db.

    We do as well.  In fact, I just assumed everyone did it that way.  Ben's editorial gave me food for thought ...

  • Bane of my current job: not only are dev, test\QA and production database names different, the schemas within each are different as well. So inside the dev database I have devschema.table, inside QA it is qaschema.table, and in production it is prodschema.table. I have yet to find a code compare tool that can handle this issue. Sure, I can ignore schema on object existence, but the code within the stored procedures? If you know of one, please do share. We do not have any sort of source control in our shop, I worked with a TFS expert at Microsoft, and he pretty much threw in the towel after a few hours. It's on my to-do list for the next year, to implement some sort of source control on database objects. I'm afraid I'm going to have to invent my own at this point. No one to blame for this head-shaker except the vendor who designed the application this way.

  • LoriB - Wednesday, November 21, 2018 4:20 PM

    Bane of my current job: not only are dev, test\QA and production database names different, the schemas within each are different as well. So inside the dev database I have devschema.table, inside QA it is qaschema.table, and in production it is prodschema.table. I have yet to find a code compare tool that can handle this issue. Sure, I can ignore schema on object existence, but the code within the stored procedures? If you know of one, please do share. We do not have any sort of source control in our shop, I worked with a TFS expert at Microsoft, and he pretty much threw in the towel after a few hours. It's on my to-do list for the next year, to implement some sort of source control on database objects. I'm afraid I'm going to have to invent my own at this point. No one to blame for this head-shaker except the vendor who designed the application this way.

    This is just an idea, so I am not totally sure it will work since I haven't experienced your situation.  Still, what if you use synonyms?  This way you could obscure the underlying dev/qa/prod schema issues.  Then at least your stored procs could be the same on all of the databases.  I am not sure if redgate sql data compare works on synonyms or not.  Anyway, it is an idea, perhaps it will work for you.
    Ben

Viewing 7 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic. Login to reply