Minh Tran (minhtran_01@yahoo.com) writes:[color=blue]
> In order to minimize the number of connection strings I have to use to
> access different databases on the same Sql Server, I was considering
> storing all stored procedures in just one database. I want to do this
> because connection pooling in my application - ASP.NET is based on
> this connection string. So if I need to access 6 different databases
> on one sql server & set 6 different connection strings, I end up
> creating 6 different connection pools.
>
> Other than it might create more management work for the DBA, are there
> any performance implications with implementing this scheme? Do stored
> procedures run any slower if they access tables that are stored in
> different databases within the same server?[/color]
The first question that strikes me is why you would have six
databases for the same application.
But given that this is not something that you cannot change, I
recommend against having all stored procedures in one database. This
is not because of performance, but one of manangement. Say that someone
says "let's set up a test environment on the the same server". If you
have hardcoded database names in your stored procedures, you lose.
The connection-string problem could easily be overcome by
always using the same database when you connect, and then specify
the procedure as db.owner.sp.
--
Erland Sommarskog, SQL Server MVP,
esquel@sommarskog.se
Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp