Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
cat_jesus
Aged Yak Warrior
547 Posts |
 Posted - 2003-02-04 : 11:13:51
|
| I have a situation where we use a database created by a third party vendor with closed source executables. Our database runs on SQL 7.0 on a win2k server. For years we have put our site specific code for interfaces and reports in the same database. Because of some of our interface and reporting processes we have seen a huge jump in the size of the log. To address this issue and to give us a clearly defined migration path I have proposed that we move all of our code that doesn't update the third party tables to a separate database. We would then have another database that is our stage database before it gets to the prod reporting database.So here is the structure now.PRDDATA -- production databaseHere's what I want it to be PRDDATA -- production databaseINTFDATA -- interface and reporting processes and tablesSTAGEDATA -- staging database/migration path to INTFDATAThe SPs in the INTFDATA database will necessarily have to use fully qualified database names in the select statements that access it. for example:select something intoreportsfrom PRDDATA.dbo.ADDRESSjoin another table...I am getting a great deal of resistence from the DBAs and citrix teams because they do not think I should have a PRDDATA database on a dev server. They have not been able to clearly explain why they have a problem with this other than "you might get confused about which server you are on if the database name is the same.". This seems like a pretty lame excuse.The citrix team is claiming that there was once a problem where citrix got confused about which server it was pointing to because the database name in dev and prod were the same. This doesn't sound right to me either. As far as I know any connection to a SQL server requires that you explicitly point to the server. When pressed for details they are unable to provide them and tell me to just trust them, they know best.Is there any reason you can think of for having a rule that prod database names canot be the same as dev database names besides "you might get confused"? Do you know of a better way to separate out our reporting tables and SPs without having to do a code change when we move from test to prod? |
|
|
tkizer
Almighty SQL Goddess
38200 Posts |
Posted - 2003-02-04 : 11:22:29
|
| Well I would not personally name the database PRDDATA, but that is my personal preference.As far as the Citrix team claiming that a problem occurred before because the prod database and the dev database were named the same, they are just pulling your leg or are thinking of a different scenario because it just didn't happen. We always (well almost always) use the same database name in our different environments.I don't understand why it would require a code change if you use different database names. The database name should not be hard coded into your application. It should be stored in a connection string outside of the application, like in the registry or a flat file. |
 |
|
|
robvolk
Most Valuable Yak
15732 Posts |
Posted - 2003-02-04 : 11:24:55
|
quote:
They have not been able to clearly explain why they have a problem with this other than "you might get confused about which server you are on if the database name is the same."....The citrix team is claiming that there was once a problem where citrix got confused about which server it was pointing to because the database name in dev and prod were the same.
That's funny! Citrix might get confused! And who sets up and programs the Citrix server I wonder?Some very nice waltzing with pronouns on the part of your DBA and Citrix people. They're trying to make it sound like you might get confused when in fact THEY are the ones who might get confused, and don't want to be responsible for any problems that arise from their confusion.One point that should be clarified: are you talking about having 3 databases on one existing (production) server? Or having 3 databases on another server? If there are 2 servers, will they be splitting production data between them or will one server simply be holding a mirror of the production data? (in other words, is the production data fully housed on one server?) You intermingled "database" and "server" in your post and it changes the question considerably. |
|
|
|
KnooKie
Aged Yak Warrior
623 Posts |
Posted - 2003-02-04 : 11:29:58
|
| we had that exact scenario for a while with absolutely no problems whatsoever and that was using a version of citrix a few years ago.===========Paul |
|
|
|
cat_jesus
Aged Yak Warrior
547 Posts |
Posted - 2003-02-04 : 11:37:13
|
| tduggan,Code changes when moving code into prod(specifically into the interfact DB) would be required because the code changes are in SPs and the SPs are referencing tables outside of their database.Robvolk, Yes I am talking about having three databases on the prod server and the same three on the dev(and test) server. This way when we develop our stored procedures we can simply move them into prod without having to modify code. The data will only be moving between databases on the same server, never between servers(in the context of this discussion anyway). And the stage database will only be used to verify that new code works properly, kind of like a lengthened parallel test in prod.It seemed pretty reasonable to me, but I have been getting a great deal of flak about this. I think you're right about waltzing with pronouns. It's never about what confuses them or what they don't understand. |
|
|
|
robvolk
Most Valuable Yak
15732 Posts |
Posted - 2003-02-04 : 12:17:22
|
I'm also curious about whatever logic they have regarding moving the code from dev to production. How can rolling out tested code be more confusing than having to review every line and make changes? Kinda defeats the purpose of developing and debugging code if it needs to be rewritten when deployed.  Have any of these people you're dealing with ever WRITTEN code?On the off chance that these guys/gals are not bullshitting you and have genuine concerns that their arguments don't properly reflect, maybe you can sit down with 1 or 2 of the more approachable ones for a little off-the-record conversation and find out what's worrying them. Maybe get a little more insight on the problem that happened in the past. I wouldn't be surprised if it's as much a political matter as technical. Also point out, like you did earlier in this thread, that the server has to be explicitly specified when connecting to SQL Server, so the confusion about which server is which is non-existent and shouldn't affect their side of the house at all. Whatever you do, make it clear that YOU will not be confused by the setup and that they should drop that as an excuse for not moving forward. It will only make them look bad. |
|
|
|
cat_jesus
Aged Yak Warrior
547 Posts |
Posted - 2003-02-04 : 13:33:42
|
quote:
I'm also curious about whatever logic they have regarding moving the code from dev to production. How can rolling out tested code be more confusing than having to review every line and make changes? Kinda defeats the purpose of developing and debugging code if it needs to be rewritten when deployed. Have any of these people you're dealing with ever WRITTEN code?
Well one of the people I'm dealing with is on my team and writes code. Well that's what he calls it. I've been looking for another term to describe it but haven't come across it yet. He is suggesting that for the new database that we abstract each table as a view so we can keep the code the same and just change the views. One of these processes is very resource intensive and it would add an unnecessary layer of complexity and slow the process down.quote:
On the off chance that these guys/gals are not bullshitting you and have genuine concerns that their arguments don't properly reflect, maybe you can sit down with 1 or 2 of the more approachable ones for a little off-the-record conversation and find out what's worrying them. Maybe get a little more insight on the problem that happened in the past.
Unfortunately none of them are very approachable. They are the elite systems people and they know best.quote:
I wouldn't be surprised if it's as much a political matter as technical.
I think what happened was there was some configuration problem with citrix in the past and the citrix administrator, rather than admit her error, put forth the notion that the problem was with having the databases named the same but on different servers. Now the details have been forgotten but the rule against duplicate database names on different servers has become institutionalized. Now it's, "that's the way we do things here".quote:
Also point out, like you did earlier in this thread, that the server has to be explicitly specified when connecting to SQL Server, so the confusion about which server is which is non-existent and shouldn't affect their side of the house at all.
I will do this. I think we need to change the rule.quote:
Whatever you do, make it clear that YOU will not be confused by the setup and that they should drop that as an excuse for not moving forward. It will only make them look bad.
I'll do this too. |
|
|
|
|
|
|
|
|
Database naming