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.
> >>
>