Best Practices: Should other (unrelated) applications be installed on a SQL server?

I was taught long ago that database servers should be database servers
and nothing more. I have been asked by my current employer to install
a new application on our SQL server because "we aren't using all of
it." In other words, they feel the server is under-utilized and want
to run other applications on it. I told them this was a bad idea and
that we should identify another server for the installation. That was
rejected and I've been challenged to "prove" that best practices are
to avoid loading unrelated applications on a database server.
Can anyone point me to a statement from Microsoft or some DB authority
that says as much? I have located dozens of bloggers who agree with
me but I can't really cite "CyberDawg420" as a reference when making
my argument. Any help at all is greatly appreciated!
You seem to be trying to "prove" common sense.
How about this. Don't share unless there is absolutely no choice.
Geoff N. Hiten
Senior SQL Infrastructure Consultant
Microsoft SQL Server MVP
<jimguytrucker@.yahoo.com> wrote in message
news:1194452329.877280.250570@.v3g2000hsg.googlegro ups.com...
>I was taught long ago that database servers should be database servers
> and nothing more. I have been asked by my current employer to install
> a new application on our SQL server because "we aren't using all of
> it." In other words, they feel the server is under-utilized and want
> to run other applications on it. I told them this was a bad idea and
> that we should identify another server for the installation. That was
> rejected and I've been challenged to "prove" that best practices are
> to avoid loading unrelated applications on a database server.
> Can anyone point me to a statement from Microsoft or some DB authority
> that says as much? I have located dozens of bloggers who agree with
> me but I can't really cite "CyberDawg420" as a reference when making
> my argument. Any help at all is greatly appreciated!
>
|||On Nov 7, 10:38 am, "Geoff N. Hiten" <SQLCrafts...@.gmail.com> wrote:
> You seem to be trying to "prove" common sense.
> How about this. Don't share unless there is absolutely no choice.
> --
> Geoff N. Hiten
> Senior SQL Infrastructure Consultant
> Microsoft SQL Server MVP
> <jimguytruc...@.yahoo.com> wrote in message
> news:1194452329.877280.250570@.v3g2000hsg.googlegro ups.com...
>
>
> - Show quoted text -
You are spot on with the "common sense" comment. I'm frustrated
because it is obvious to me but they want "evidence." The only way to
PROVE I'm right is to do what they ask, slow down the SQL server, and
create numerous headaches. I would be willing to do this to make my
point but I'm the one who would have to clean up the aftermath.

Best Practices: Should other (unrelated) applications be installed on a SQL server?

I was taught long ago that database servers should be database servers
and nothing more. I have been asked by my current employer to install
a new application on our SQL server because "we aren't using all of
it." In other words, they feel the server is under-utilized and want
to run other applications on it. I told them this was a bad idea and
that we should identify another server for the installation. That was
rejected and I've been challenged to "prove" that best practices are
to avoid loading unrelated applications on a database server.
Can anyone point me to a statement from Microsoft or some DB authority
that says as much? I have located dozens of bloggers who agree with
me but I can't really cite "CyberDawg420" as a reference when making
my argument. Any help at all is greatly appreciated!You seem to be trying to "prove" common sense.
How about this. Don't share unless there is absolutely no choice.
--
Geoff N. Hiten
Senior SQL Infrastructure Consultant
Microsoft SQL Server MVP
<jimguytrucker@.yahoo.com> wrote in message
news:1194452329.877280.250570@.v3g2000hsg.googlegroups.com...
>I was taught long ago that database servers should be database servers
> and nothing more. I have been asked by my current employer to install
> a new application on our SQL server because "we aren't using all of
> it." In other words, they feel the server is under-utilized and want
> to run other applications on it. I told them this was a bad idea and
> that we should identify another server for the installation. That was
> rejected and I've been challenged to "prove" that best practices are
> to avoid loading unrelated applications on a database server.
> Can anyone point me to a statement from Microsoft or some DB authority
> that says as much? I have located dozens of bloggers who agree with
> me but I can't really cite "CyberDawg420" as a reference when making
> my argument. Any help at all is greatly appreciated!
>|||On Nov 7, 10:38 am, "Geoff N. Hiten" <SQLCrafts...@.gmail.com> wrote:
> You seem to be trying to "prove" common sense.
> How about this. Don't share unless there is absolutely no choice.
> --
> Geoff N. Hiten
> Senior SQL Infrastructure Consultant
> Microsoft SQL Server MVP
> <jimguytruc...@.yahoo.com> wrote in message
> news:1194452329.877280.250570@.v3g2000hsg.googlegroups.com...
>
> >I was taught long ago that database servers should be database servers
> > and nothing more. I have been asked by my current employer to install
> > a new application on our SQL server because "we aren't using all of
> > it." In other words, they feel the server is under-utilized and want
> > to run other applications on it. I told them this was a bad idea and
> > that we should identify another server for the installation. That was
> > rejected and I've been challenged to "prove" that best practices are
> > to avoid loading unrelated applications on a database server.
> > Can anyone point me to a statement from Microsoft or some DB authority
> > that says as much? I have located dozens of bloggers who agree with
> > me but I can't really cite "CyberDawg420" as a reference when making
> > my argument. Any help at all is greatly appreciated!- Hide quoted text -
> - Show quoted text -
You are spot on with the "common sense" comment. I'm frustrated
because it is obvious to me but they want "evidence." The only way to
PROVE I'm right is to do what they ask, slow down the SQL server, and
create numerous headaches. I would be willing to do this to make my
point but I'm the one who would have to clean up the aftermath.

Best Practices: Should other (unrelated) applications be installed on a SQL server?

I was taught long ago that database servers should be database servers
and nothing more. I have been asked by my current employer to install
a new application on our SQL server because "we aren't using all of
it." In other words, they feel the server is under-utilized and want
to run other applications on it. I told them this was a bad idea and
that we should identify another server for the installation. That was
rejected and I've been challenged to "prove" that best practices are
to avoid loading unrelated applications on a database server.
Can anyone point me to a statement from Microsoft or some DB authority
that says as much? I have located dozens of bloggers who agree with
me but I can't really cite "CyberDawg420" as a reference when making
my argument. Any help at all is greatly appreciated!You seem to be trying to "prove" common sense.
How about this. Don't share unless there is absolutely no choice.
Geoff N. Hiten
Senior SQL Infrastructure Consultant
Microsoft SQL Server MVP
<jimguytrucker@.yahoo.com> wrote in message
news:1194452329.877280.250570@.v3g2000hsg.googlegroups.com...
>I was taught long ago that database servers should be database servers
> and nothing more. I have been asked by my current employer to install
> a new application on our SQL server because "we aren't using all of
> it." In other words, they feel the server is under-utilized and want
> to run other applications on it. I told them this was a bad idea and
> that we should identify another server for the installation. That was
> rejected and I've been challenged to "prove" that best practices are
> to avoid loading unrelated applications on a database server.
> Can anyone point me to a statement from Microsoft or some DB authority
> that says as much? I have located dozens of bloggers who agree with
> me but I can't really cite "CyberDawg420" as a reference when making
> my argument. Any help at all is greatly appreciated!
>sql

Best Practice question

Our company has several large 3rd-party applications, each with its' own
dedicated SQL Server database. I am developing our own add-ons and utilities
that use data from these databases.
My question is, should my Views, Functions & Stored Procedures reside in the
3rd-party database (they have a standard naming convention to identify our
code), or should they be in a separate database referencing the tables, views
etc. in the 3rd-party database?
Is there any loss in efficiency by keeping our code in a separate datebase?
We are using SQL 2000 Standard.
Thank you.I don't see a problem with keeping the objects in the third-party database
as long as you have a naming convention to identify the objects and are
prepared to re-apply scripts to re-create the objects, if needed. If you
keep objects in a separate database, you'll need to create users in both
databases and can't use ownership chaining unless you enable the
'db-chaining' database option in both databases.
--
Hope this helps.
Dan Guzman
SQL Server MVP
"SQLGuptaSybase" <SQLGuptaSybase@.discussions.microsoft.com> wrote in message
news:745D6B85-63D3-4194-9213-8721D7B3713D@.microsoft.com...
> Our company has several large 3rd-party applications, each with its' own
> dedicated SQL Server database. I am developing our own add-ons and
> utilities
> that use data from these databases.
> My question is, should my Views, Functions & Stored Procedures reside in
> the
> 3rd-party database (they have a standard naming convention to identify our
> code), or should they be in a separate database referencing the tables,
> views
> etc. in the 3rd-party database?
> Is there any loss in efficiency by keeping our code in a separate
> datebase?
> We are using SQL 2000 Standard.
> Thank you.|||Dan,
Thank you for the quick response. One thing I did not address was storing
data in custom tables in the 3rd party db which I am also doing. Because the
data in the custom tables changes more frequently than the 3rd party, I use
scheduled DTS packages to copy data from the custom tables to a separate db.
Any thoughts on that?
Thank you again.
--
"Dan Guzman" wrote:
> I don't see a problem with keeping the objects in the third-party database
> as long as you have a naming convention to identify the objects and are
> prepared to re-apply scripts to re-create the objects, if needed. If you
> keep objects in a separate database, you'll need to create users in both
> databases and can't use ownership chaining unless you enable the
> 'db-chaining' database option in both databases.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "SQLGuptaSybase" <SQLGuptaSybase@.discussions.microsoft.com> wrote in message
> news:745D6B85-63D3-4194-9213-8721D7B3713D@.microsoft.com...
> > Our company has several large 3rd-party applications, each with its' own
> > dedicated SQL Server database. I am developing our own add-ons and
> > utilities
> > that use data from these databases.
> >
> > My question is, should my Views, Functions & Stored Procedures reside in
> > the
> > 3rd-party database (they have a standard naming convention to identify our
> > code), or should they be in a separate database referencing the tables,
> > views
> > etc. in the 3rd-party database?
> >
> > Is there any loss in efficiency by keeping our code in a separate
> > datebase?
> >
> > We are using SQL 2000 Standard.
> >
> > Thank you.
>|||> Any thoughts on that?
The main reason would might want to store the tables in a different database
is if you have a lot of data and the recovery/availability requirements are
different. Separation will give you more flexibility.
--
Hope this helps.
Dan Guzman
SQL Server MVP
"SQLGuptaSybase" <SQLGuptaSybase@.discussions.microsoft.com> wrote in message
news:A89EB44E-5E8C-4239-9E01-A92644E4EE3A@.microsoft.com...
> Dan,
> Thank you for the quick response. One thing I did not address was storing
> data in custom tables in the 3rd party db which I am also doing. Because
> the
> data in the custom tables changes more frequently than the 3rd party, I
> use
> scheduled DTS packages to copy data from the custom tables to a separate
> db.
> Any thoughts on that?
> Thank you again.
> --
> "Dan Guzman" wrote:
>> I don't see a problem with keeping the objects in the third-party
>> database
>> as long as you have a naming convention to identify the objects and are
>> prepared to re-apply scripts to re-create the objects, if needed. If you
>> keep objects in a separate database, you'll need to create users in both
>> databases and can't use ownership chaining unless you enable the
>> 'db-chaining' database option in both databases.
>> --
>> Hope this helps.
>> Dan Guzman
>> SQL Server MVP
>> "SQLGuptaSybase" <SQLGuptaSybase@.discussions.microsoft.com> wrote in
>> message
>> news:745D6B85-63D3-4194-9213-8721D7B3713D@.microsoft.com...
>> > Our company has several large 3rd-party applications, each with its'
>> > own
>> > dedicated SQL Server database. I am developing our own add-ons and
>> > utilities
>> > that use data from these databases.
>> >
>> > My question is, should my Views, Functions & Stored Procedures reside
>> > in
>> > the
>> > 3rd-party database (they have a standard naming convention to identify
>> > our
>> > code), or should they be in a separate database referencing the tables,
>> > views
>> > etc. in the 3rd-party database?
>> >
>> > Is there any loss in efficiency by keeping our code in a separate
>> > datebase?
>> >
>> > We are using SQL 2000 Standard.
>> >
>> > Thank you.|||Thank you.
--
"Dan Guzman" wrote:
> > Any thoughts on that?
> The main reason would might want to store the tables in a different database
> is if you have a lot of data and the recovery/availability requirements are
> different. Separation will give you more flexibility.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "SQLGuptaSybase" <SQLGuptaSybase@.discussions.microsoft.com> wrote in message
> news:A89EB44E-5E8C-4239-9E01-A92644E4EE3A@.microsoft.com...
> > Dan,
> >
> > Thank you for the quick response. One thing I did not address was storing
> > data in custom tables in the 3rd party db which I am also doing. Because
> > the
> > data in the custom tables changes more frequently than the 3rd party, I
> > use
> > scheduled DTS packages to copy data from the custom tables to a separate
> > db.
> > Any thoughts on that?
> >
> > Thank you again.
> > --
> >
> > "Dan Guzman" wrote:
> >
> >> I don't see a problem with keeping the objects in the third-party
> >> database
> >> as long as you have a naming convention to identify the objects and are
> >> prepared to re-apply scripts to re-create the objects, if needed. If you
> >> keep objects in a separate database, you'll need to create users in both
> >> databases and can't use ownership chaining unless you enable the
> >> 'db-chaining' database option in both databases.
> >>
> >> --
> >> Hope this helps.
> >>
> >> Dan Guzman
> >> SQL Server MVP
> >>
> >> "SQLGuptaSybase" <SQLGuptaSybase@.discussions.microsoft.com> wrote in
> >> message
> >> news:745D6B85-63D3-4194-9213-8721D7B3713D@.microsoft.com...
> >> > Our company has several large 3rd-party applications, each with its'
> >> > own
> >> > dedicated SQL Server database. I am developing our own add-ons and
> >> > utilities
> >> > that use data from these databases.
> >> >
> >> > My question is, should my Views, Functions & Stored Procedures reside
> >> > in
> >> > the
> >> > 3rd-party database (they have a standard naming convention to identify
> >> > our
> >> > code), or should they be in a separate database referencing the tables,
> >> > views
> >> > etc. in the 3rd-party database?
> >> >
> >> > Is there any loss in efficiency by keeping our code in a separate
> >> > datebase?
> >> >
> >> > We are using SQL 2000 Standard.
> >> >
> >> > Thank you.
> >>
>

Best place for company info?

Say I have 4 applications which each use their own database. There are two
SQL Servers involved and the databases are split across servers like this:
SQLServer1
- BigApp1
- SmallApp1
SQLServer2
- BigApp2
- SmallApp2
The above helps balance load. If I want to store information about the
company developing these applications (such as company name, address, phone
number, etc), where should I put it? In a seperate database or in one of
the application databases?
This information will be idenpendent of any application but all applications
will reference it.
Thanks,
BrettHi
It is not clear if this is one company per application or one company for
all applications. I would add this information to each database if the
information is application specific, you could create a partitioned view if
you wish to view all values. If this is a common information, then I would
consider adding it to it's own database along with any other common/shared
information.
John
"Brett" <no@.spam.net> wrote in message
news:%23BLwNcXLFHA.724@.TK2MSFTNGP14.phx.gbl...
> Say I have 4 applications which each use their own database. There are
> two SQL Servers involved and the databases are split across servers like
> this:
> SQLServer1
> - BigApp1
> - SmallApp1
> SQLServer2
> - BigApp2
> - SmallApp2
> The above helps balance load. If I want to store information about the
> company developing these applications (such as company name, address,
> phone number, etc), where should I put it? In a seperate database or in
> one of the application databases?
> This information will be idenpendent of any application but all
> applications will reference it.
> Thanks,
> Brett
>|||One company owns all four applications. It is the parent of these four
apps. I thought about putting the company info in its own database but that
creates additional connections and use of resources right?
Each of the four databases has its own website. The websites run CFMX,
which creates a connection to its respective database. If the company info
is in its on database in either SQLServer1 or SQLServer2, would that create
more connections?
If not, which server should that database go on - SQLServer1 or SQLServer2,
with respect to load balancing since all four websites will be accessing the
company database (displaying company info on certain pages of the website
for example). It can eleviate some of the load problem by storing the
company info in an application variable.
Thanks,
Brett
"John Bell" <jbellnewsposts@.hotmail.com> wrote in message
news:uyDwXBYLFHA.1172@.TK2MSFTNGP12.phx.gbl...
> Hi
> It is not clear if this is one company per application or one company for
> all applications. I would add this information to each database if the
> information is application specific, you could create a partitioned view
> if you wish to view all values. If this is a common information, then I
> would consider adding it to it's own database along with any other
> common/shared information.
> John
>
> "Brett" <no@.spam.net> wrote in message
> news:%23BLwNcXLFHA.724@.TK2MSFTNGP14.phx.gbl...
>|||How much info are you talking about? And how often is it updated? By
putting the same duplicate info in separate databases, you make updates to
that info a little trickier. Are you using Replication to keep the
databases in sync? If so, then it would seem you could put it on both and
that would handle most of the update issues. Of course, as you point out,
if there's only a couple of lines of information, it might make more sense
to put it in application variables and skip the DB overhead altogether...
"Brett" <no@.spam.net> wrote in message
news:%23ya4AJYLFHA.568@.TK2MSFTNGP09.phx.gbl...
> One company owns all four applications. It is the parent of these four
> apps. I thought about putting the company info in its own database but
> that creates additional connections and use of resources right?
> Each of the four databases has its own website. The websites run CFMX,
> which creates a connection to its respective database. If the company
> info is in its on database in either SQLServer1 or SQLServer2, would that
> create more connections?
> If not, which server should that database go on - SQLServer1 or
> SQLServer2, with respect to load balancing since all four websites will be
> accessing the company database (displaying company info on certain pages
> of the website for example). It can eleviate some of the load problem by
> storing the company info in an application variable.
> Thanks,
> Brett
> "John Bell" <jbellnewsposts@.hotmail.com> wrote in message
> news:uyDwXBYLFHA.1172@.TK2MSFTNGP12.phx.gbl...
>|||The info won't be much but may grow. It will be items such as:
- Company name
- address
- tel/fax numbers
- maybe company employees and their details
- may a map URL
and what ever else.
The info won't be updated often. Maybe 5 times/mo or so. Logically it is
completely independent of any application or database. It will need to be
in a database. Just, do I want to put it inside of an existing application
database or its own?
The application variables for each app will still need to get the info from
somewhere. I don't want them hard coded. That's why I'd like the database
setup. One change, one place.
Any application will hit the company info DB maybe once/w to get updates.
Little overhead actually.
Suggestions?
Thanks,
Brett
"Michael C#" <xyz@.abcdef.com> wrote in message
news:zEk%d.1527$BX1.327@.fe08.lga...
> How much info are you talking about? And how often is it updated? By
> putting the same duplicate info in separate databases, you make updates to
> that info a little trickier. Are you using Replication to keep the
> databases in sync? If so, then it would seem you could put it on both and
> that would handle most of the update issues. Of course, as you point out,
> if there's only a couple of lines of information, it might make more sense
> to put it in application variables and skip the DB overhead altogether...
> "Brett" <no@.spam.net> wrote in message
> news:%23ya4AJYLFHA.568@.TK2MSFTNGP09.phx.gbl...
>|||Sounds like you're leaning toward putting it in its own database. That
being the case, unless it's specifically tied to the data stored in one of
your current databases, it makes sense to create a separate database for it.
And if you decide you want to access the data from within your other
database, just fully qualify the table names in your queries. It also
sounds like the information (company employees/details, etc.) could be
subject to a some growth/changes.
"Brett" <no@.spam.net> wrote in message
news:OcgM$zYLFHA.244@.TK2MSFTNGP12.phx.gbl...
> The info won't be much but may grow. It will be items such as:
> - Company name
> - address
> - tel/fax numbers
> - maybe company employees and their details
> - may a map URL
> and what ever else.
> The info won't be updated often. Maybe 5 times/mo or so. Logically it is
> completely independent of any application or database. It will need to be
> in a database. Just, do I want to put it inside of an existing
> application database or its own?
> The application variables for each app will still need to get the info
> from somewhere. I don't want them hard coded. That's why I'd like the
> database setup. One change, one place.
> Any application will hit the company info DB maybe once/w to get
> updates. Little overhead actually.
> Suggestions?
> Thanks,
> Brett
> "Michael C#" <xyz@.abcdef.com> wrote in message
> news:zEk%d.1527$BX1.327@.fe08.lga...
>|||Hi
"Brett" <no@.spam.net> wrote in message
news:%23ya4AJYLFHA.568@.TK2MSFTNGP09.phx.gbl...
> One company owns all four applications. It is the parent of these four
> apps. I thought about putting the company info in its own database but
> that creates additional connections and use of resources right?
You can always create a view.
> Each of the four databases has its own website. The websites run CFMX,
> which creates a connection to its respective database. If the company
> info is in its on database in either SQLServer1 or SQLServer2, would that
> create more connections?
> If not, which server should that database go on - SQLServer1 or
> SQLServer2, with respect to load balancing since all four websites will be
> accessing the company database (displaying company info on certain pages
> of the website for example). It can eleviate some of the load problem by
> storing the company info in an application variable.
This would depend on how/when it is updated and how/how often it is used and
if you always have to display the current information that is in the table.
You may want to consider using replication as suggested by Michael.
John
> Thanks,
> Brett
> "John Bell" <jbellnewsposts@.hotmail.com> wrote in message
> news:uyDwXBYLFHA.1172@.TK2MSFTNGP12.phx.gbl...
>|||Yes - this all true.
If the company DB is on a server seperate from a DB that wish to call data
from the company DB, how do I fully qualify the company DB table path in say
a SELECT?
Thanks,
Brett
"Michael C#" <xyz@.abcdef.com> wrote in message
news:0ml%d.11715$xQ5.2876@.fe10.lga...
> Sounds like you're leaning toward putting it in its own database. That
> being the case, unless it's specifically tied to the data stored in one of
> your current databases, it makes sense to create a separate database for
> it. And if you decide you want to access the data from within your other
> database, just fully qualify the table names in your queries. It also
> sounds like the information (company employees/details, etc.) could be
> subject to a some growth/changes.
> "Brett" <no@.spam.net> wrote in message
> news:OcgM$zYLFHA.244@.TK2MSFTNGP12.phx.gbl...
>|||"John Bell" <jbellnewsposts@.hotmail.com> wrote in message
news:Ol5aFBZLFHA.576@.TK2MSFTNGP15.phx.gbl...
> Hi
> "Brett" <no@.spam.net> wrote in message
> news:%23ya4AJYLFHA.568@.TK2MSFTNGP09.phx.gbl...
> You can always create a view.
> This would depend on how/when it is updated and how/how often it is used
> and if you always have to display the current information that is in the
> table. You may want to consider using replication as suggested by Michael.
Wouldn't replication cause more overhead than the once/w query from each
application?
Thanks,
Brett|||On a separate server? You're jumping around a little bit here. To answer
your question, look up sp_addlinkedserver in BOL.
"Brett" <no@.spam.net> wrote in message
news:O7sbMRZLFHA.3356@.TK2MSFTNGP12.phx.gbl...
> Yes - this all true.
> If the company DB is on a server seperate from a DB that wish to call data
> from the company DB, how do I fully qualify the company DB table path in
> say a SELECT?
> Thanks,
> Brett
> "Michael C#" <xyz@.abcdef.com> wrote in message
> news:0ml%d.11715$xQ5.2876@.fe10.lga...
>