multiple databases vs single db ASP model

I'm looking for more opinions on a single vs many database option for our ne
w
architecture.
Background:
We are an ASP. We host website portals for organizations around the world.
We don't own the data we store and security is a large concern. Currently w
e
maintain separate databases for each client. Most of the schemas are
different, however we customize some tables based on individual client needs
.
All of our websites are currently maintained as separate webisites, with
distinct html/asp code, but a shared set of isapi dlls.
We are in the beginning stages of designing a new architecture to reduce our
adminstrative nightmare of maintenance specifically with the multiple
html/asp code bases, but would like to simplify everywhere possible.
There are 3 scenarios we are considering.
1. Combine all databases in to one.
2. Combining all trivial/similar data into one db, but keeping the most
confidential data in separate databases.
3. Continuing the same as we are now with each client in separate databases
.
#1 would be ideal, but i have the following concerns:
Security.
Problems are all or nothing, if all clients users info is in one table, all
sites would be unavailable
Restoring a table information for one specific client becomes a nightmare.
Possible locking/blocking. We do large scale updates of 100,000s rows at a
time to insert/update one client's data. I would think this would cause
performance issues for all sites during that period.
#2 seems like a good approach, because it allows specific customizations and
constraints to client tables and lessens the administrative issues with
applying changes to structures and sp's across multiple databases.
I'm guessing we can overcome some of the issues with #1 but it will require
more work in the long run. I'm looking for any thoughts on the subject.
Thanks,
SteveJust a few random thoughts... remember they're worth exactly what you paid
for them
Most of the ASPs I've dealt with run one or more SQL Servers, but maintain a
separate database for each client. I've even written back-end applications
that automate the process of creating and securing databases for new
customers. I personally think that would probably be your best bet, since
your clients tend to have different schemas anyway. This gives your clients
access to the SQL Server, but only in their limited database. They don't
even have to know your other customers' databases exist.
Also, from a legal standpoint, this may be a requirement in some industries
that your clients may be in. I know that in some financial services,
insurance and other industries, laws for maintaining data integrity are
pretty strict. In some industries I've even seen where different
subsidiaries of the same corporation (really big in the insurance industry)
can't legally store data in the same databases, due to restrictions imposed
by law.
Obviously you can create a master database with information pertaining to
each client, such as billing info, space used, statistics, etc. But other
than that, intermingling customer data can cause legal and other problems.|||> Also, from a legal standpoint, this may be a requirement in some
industries
> that your clients may be in. I know that in some financial services,
> insurance and other industries, laws for maintaining data integrity are
> pretty strict. In some industries I've even seen where different
> subsidiaries of the same corporation (really big in the insurance
industry)
> can't legally store data in the same databases, due to restrictions
imposed
> by law.
In fact, it is often the case in this extreme, that the customer's data must
live on a different *server* than your other customers' data, not just in a
different database.
A|||Thanks for the information. Would you happen to have links with references
to such laws? We aren't in a finacial or health care industry, but do deal
with goverment funded institutions. And none of our RFC's have referenced
this, but I'd like to see some instances where this comes into play.
Thanks again,
Steve
"Aaron [SQL Server MVP]" wrote:

> industries
> industry)
> imposed
> In fact, it is often the case in this extreme, that the customer's data mu
st
> live on a different *server* than your other customers' data, not just in
a
> different database.
> A
>
>|||> Thanks for the information. Would you happen to have links with
references
> to such laws?
Personally, I don't know that there are laws per se, but I know that if a
client wants that (e.g. Fidelity is a prime example), they're going to
demand it, and you will lose the business if you don't provide it, because
it is part of their requirement for every vendor.
Please post DDL, sample data and desired results.
See http://www.aspfaq.com/5006 for info.|||I know it's big in the Insurance Industry, although I don't know what the
specific laws are. It might be part of Sarbanes-Oxley. I would use that as
a starting point to find out more. Specifically, as far as I know it tends
to affect the Financial Services sector (including banks, credit unions,
brokerages, etc.) and it mostly gets into anti-trust law, although I
wouldn't doubt that other industries like Health Care, etc., might have
similar laws and regulations.
"Steve Zohn" <SteveZohn@.discussions.microsoft.com> wrote in message
news:B68ED433-BB5C-4F2B-9758-524FBDEC1095@.microsoft.com...[vbcol=seagreen]
> Thanks for the information. Would you happen to have links with
> references
> to such laws? We aren't in a finacial or health care industry, but do
> deal
> with goverment funded institutions. And none of our RFC's have referenced
> this, but I'd like to see some instances where this comes into play.
> Thanks again,
> Steve
> "Aaron [SQL Server MVP]" wrote:
>|||Actually there are laws in place I had a heckuva time setting up
software for a client because their data had to be completely separate from
their parent company, due to laws/regulations in financial services. Even
though one was the parent company of the other, they were considered to be
"in competition" with one another, and therefore couldn't share data.
"Aaron [SQL Server MVP]" <ten.xoc@.dnartreb.noraa> wrote in message
news:%23cbaz2OKFHA.1392@.TK2MSFTNGP10.phx.gbl...
> references
> Personally, I don't know that there are laws per se, but I know that if a
> client wants that (e.g. Fidelity is a prime example), they're going to
> demand it, and you will lose the business if you don't provide it, because
> it is part of their requirement for every vendor.
> --
> Please post DDL, sample data and desired results.
> See http://www.aspfaq.com/5006 for info.
>|||Thanks. I'm very pro on the multiple databases, I'm trying to come up with
solid reasons to argue against an outside consultant that is insisting that
a
single database solution is the only right solution.
"Michael C#" wrote:

> I know it's big in the Insurance Industry, although I don't know what the
> specific laws are. It might be part of Sarbanes-Oxley. I would use that
as
> a starting point to find out more. Specifically, as far as I know it tend
s
> to affect the Financial Services sector (including banks, credit unions,
> brokerages, etc.) and it mostly gets into anti-trust law, although I
> wouldn't doubt that other industries like Health Care, etc., might have
> similar laws and regulations.
> "Steve Zohn" <SteveZohn@.discussions.microsoft.com> wrote in message
> news:B68ED433-BB5C-4F2B-9758-524FBDEC1095@.microsoft.com...
>
>

multiple databases vs single db ASP model

I'm looking for more opinions on a single vs many database option for our new
architecture.
Background:
We are an ASP. We host website portals for organizations around the world.
We don't own the data we store and security is a large concern. Currently we
maintain separate databases for each client. Most of the schemas are
different, however we customize some tables based on individual client needs.
All of our websites are currently maintained as separate webisites, with
distinct html/asp code, but a shared set of isapi dlls.
We are in the beginning stages of designing a new architecture to reduce our
adminstrative nightmare of maintenance specifically with the multiple
html/asp code bases, but would like to simplify everywhere possible.
There are 3 scenarios we are considering.
1. Combine all databases in to one.
2. Combining all trivial/similar data into one db, but keeping the most
confidential data in separate databases.
3. Continuing the same as we are now with each client in separate databases.
#1 would be ideal, but i have the following concerns:
Security.
Problems are all or nothing, if all clients users info is in one table, all
sites would be unavailable
Restoring a table information for one specific client becomes a nightmare.
Possible locking/blocking. We do large scale updates of 100,000s rows at a
time to insert/update one client's data. I would think this would cause
performance issues for all sites during that period.
#2 seems like a good approach, because it allows specific customizations and
constraints to client tables and lessens the administrative issues with
applying changes to structures and sp's across multiple databases.
I'm guessing we can overcome some of the issues with #1 but it will require
more work in the long run. I'm looking for any thoughts on the subject.
Thanks,
Steve
Just a few random thoughts... remember they're worth exactly what you paid
for them
Most of the ASPs I've dealt with run one or more SQL Servers, but maintain a
separate database for each client. I've even written back-end applications
that automate the process of creating and securing databases for new
customers. I personally think that would probably be your best bet, since
your clients tend to have different schemas anyway. This gives your clients
access to the SQL Server, but only in their limited database. They don't
even have to know your other customers' databases exist.
Also, from a legal standpoint, this may be a requirement in some industries
that your clients may be in. I know that in some financial services,
insurance and other industries, laws for maintaining data integrity are
pretty strict. In some industries I've even seen where different
subsidiaries of the same corporation (really big in the insurance industry)
can't legally store data in the same databases, due to restrictions imposed
by law.
Obviously you can create a master database with information pertaining to
each client, such as billing info, space used, statistics, etc. But other
than that, intermingling customer data can cause legal and other problems.
|||> Also, from a legal standpoint, this may be a requirement in some
industries
> that your clients may be in. I know that in some financial services,
> insurance and other industries, laws for maintaining data integrity are
> pretty strict. In some industries I've even seen where different
> subsidiaries of the same corporation (really big in the insurance
industry)
> can't legally store data in the same databases, due to restrictions
imposed
> by law.
In fact, it is often the case in this extreme, that the customer's data must
live on a different *server* than your other customers' data, not just in a
different database.
A
|||Thanks for the information. Would you happen to have links with references
to such laws? We aren't in a finacial or health care industry, but do deal
with goverment funded institutions. And none of our RFC's have referenced
this, but I'd like to see some instances where this comes into play.
Thanks again,
Steve
"Aaron [SQL Server MVP]" wrote:

> industries
> industry)
> imposed
> In fact, it is often the case in this extreme, that the customer's data must
> live on a different *server* than your other customers' data, not just in a
> different database.
> A
>
>
|||> Thanks for the information. Would you happen to have links with
references
> to such laws?
Personally, I don't know that there are laws per se, but I know that if a
client wants that (e.g. Fidelity is a prime example), they're going to
demand it, and you will lose the business if you don't provide it, because
it is part of their requirement for every vendor.
Please post DDL, sample data and desired results.
See http://www.aspfaq.com/5006 for info.
|||I know it's big in the Insurance Industry, although I don't know what the
specific laws are. It might be part of Sarbanes-Oxley. I would use that as
a starting point to find out more. Specifically, as far as I know it tends
to affect the Financial Services sector (including banks, credit unions,
brokerages, etc.) and it mostly gets into anti-trust law, although I
wouldn't doubt that other industries like Health Care, etc., might have
similar laws and regulations.
"Steve Zohn" <SteveZohn@.discussions.microsoft.com> wrote in message
news:B68ED433-BB5C-4F2B-9758-524FBDEC1095@.microsoft.com...[vbcol=seagreen]
> Thanks for the information. Would you happen to have links with
> references
> to such laws? We aren't in a finacial or health care industry, but do
> deal
> with goverment funded institutions. And none of our RFC's have referenced
> this, but I'd like to see some instances where this comes into play.
> Thanks again,
> Steve
> "Aaron [SQL Server MVP]" wrote:
|||Actually there are laws in place I had a heckuva time setting up
software for a client because their data had to be completely separate from
their parent company, due to laws/regulations in financial services. Even
though one was the parent company of the other, they were considered to be
"in competition" with one another, and therefore couldn't share data.
"Aaron [SQL Server MVP]" <ten.xoc@.dnartreb.noraa> wrote in message
news:%23cbaz2OKFHA.1392@.TK2MSFTNGP10.phx.gbl...
> references
> Personally, I don't know that there are laws per se, but I know that if a
> client wants that (e.g. Fidelity is a prime example), they're going to
> demand it, and you will lose the business if you don't provide it, because
> it is part of their requirement for every vendor.
> --
> Please post DDL, sample data and desired results.
> See http://www.aspfaq.com/5006 for info.
>
|||Thanks. I'm very pro on the multiple databases, I'm trying to come up with
solid reasons to argue against an outside consultant that is insisting that a
single database solution is the only right solution.
"Michael C#" wrote:

> I know it's big in the Insurance Industry, although I don't know what the
> specific laws are. It might be part of Sarbanes-Oxley. I would use that as
> a starting point to find out more. Specifically, as far as I know it tends
> to affect the Financial Services sector (including banks, credit unions,
> brokerages, etc.) and it mostly gets into anti-trust law, although I
> wouldn't doubt that other industries like Health Care, etc., might have
> similar laws and regulations.
> "Steve Zohn" <SteveZohn@.discussions.microsoft.com> wrote in message
> news:B68ED433-BB5C-4F2B-9758-524FBDEC1095@.microsoft.com...
>
>

multiple databases vs single db ASP model

I'm looking for more opinions on a single vs many database option for our new
architecture.
Background:
We are an ASP. We host website portals for organizations around the world.
We don't own the data we store and security is a large concern. Currently we
maintain separate databases for each client. Most of the schemas are
different, however we customize some tables based on individual client needs.
All of our websites are currently maintained as separate webisites, with
distinct html/asp code, but a shared set of isapi dlls.
We are in the beginning stages of designing a new architecture to reduce our
adminstrative nightmare of maintenance specifically with the multiple
html/asp code bases, but would like to simplify everywhere possible.
There are 3 scenarios we are considering.
1. Combine all databases in to one.
2. Combining all trivial/similar data into one db, but keeping the most
confidential data in separate databases.
3. Continuing the same as we are now with each client in separate databases.
#1 would be ideal, but i have the following concerns:
Security.
Problems are all or nothing, if all clients users info is in one table, all
sites would be unavailable
Restoring a table information for one specific client becomes a nightmare.
Possible locking/blocking. We do large scale updates of 100,000s rows at a
time to insert/update one client's data. I would think this would cause
performance issues for all sites during that period.
#2 seems like a good approach, because it allows specific customizations and
constraints to client tables and lessens the administrative issues with
applying changes to structures and sp's across multiple databases.
I'm guessing we can overcome some of the issues with #1 but it will require
more work in the long run. I'm looking for any thoughts on the subject.
Thanks,
SteveJust a few random thoughts... remember they're worth exactly what you paid
for them :)
Most of the ASPs I've dealt with run one or more SQL Servers, but maintain a
separate database for each client. I've even written back-end applications
that automate the process of creating and securing databases for new
customers. I personally think that would probably be your best bet, since
your clients tend to have different schemas anyway. This gives your clients
access to the SQL Server, but only in their limited database. They don't
even have to know your other customers' databases exist.
Also, from a legal standpoint, this may be a requirement in some industries
that your clients may be in. I know that in some financial services,
insurance and other industries, laws for maintaining data integrity are
pretty strict. In some industries I've even seen where different
subsidiaries of the same corporation (really big in the insurance industry)
can't legally store data in the same databases, due to restrictions imposed
by law.
Obviously you can create a master database with information pertaining to
each client, such as billing info, space used, statistics, etc. But other
than that, intermingling customer data can cause legal and other problems.|||> Also, from a legal standpoint, this may be a requirement in some
industries
> that your clients may be in. I know that in some financial services,
> insurance and other industries, laws for maintaining data integrity are
> pretty strict. In some industries I've even seen where different
> subsidiaries of the same corporation (really big in the insurance
industry)
> can't legally store data in the same databases, due to restrictions
imposed
> by law.
In fact, it is often the case in this extreme, that the customer's data must
live on a different *server* than your other customers' data, not just in a
different database.
A|||Thanks for the information. Would you happen to have links with references
to such laws? We aren't in a finacial or health care industry, but do deal
with goverment funded institutions. And none of our RFC's have referenced
this, but I'd like to see some instances where this comes into play.
Thanks again,
Steve
"Aaron [SQL Server MVP]" wrote:
> > Also, from a legal standpoint, this may be a requirement in some
> industries
> > that your clients may be in. I know that in some financial services,
> > insurance and other industries, laws for maintaining data integrity are
> > pretty strict. In some industries I've even seen where different
> > subsidiaries of the same corporation (really big in the insurance
> industry)
> > can't legally store data in the same databases, due to restrictions
> imposed
> > by law.
> In fact, it is often the case in this extreme, that the customer's data must
> live on a different *server* than your other customers' data, not just in a
> different database.
> A
>
>|||> Thanks for the information. Would you happen to have links with
references
> to such laws?
Personally, I don't know that there are laws per se, but I know that if a
client wants that (e.g. Fidelity is a prime example), they're going to
demand it, and you will lose the business if you don't provide it, because
it is part of their requirement for every vendor.
--
Please post DDL, sample data and desired results.
See http://www.aspfaq.com/5006 for info.|||I know it's big in the Insurance Industry, although I don't know what the
specific laws are. It might be part of Sarbanes-Oxley. I would use that as
a starting point to find out more. Specifically, as far as I know it tends
to affect the Financial Services sector (including banks, credit unions,
brokerages, etc.) and it mostly gets into anti-trust law, although I
wouldn't doubt that other industries like Health Care, etc., might have
similar laws and regulations.
"Steve Zohn" <SteveZohn@.discussions.microsoft.com> wrote in message
news:B68ED433-BB5C-4F2B-9758-524FBDEC1095@.microsoft.com...
> Thanks for the information. Would you happen to have links with
> references
> to such laws? We aren't in a finacial or health care industry, but do
> deal
> with goverment funded institutions. And none of our RFC's have referenced
> this, but I'd like to see some instances where this comes into play.
> Thanks again,
> Steve
> "Aaron [SQL Server MVP]" wrote:
>> > Also, from a legal standpoint, this may be a requirement in some
>> industries
>> > that your clients may be in. I know that in some financial services,
>> > insurance and other industries, laws for maintaining data integrity are
>> > pretty strict. In some industries I've even seen where different
>> > subsidiaries of the same corporation (really big in the insurance
>> industry)
>> > can't legally store data in the same databases, due to restrictions
>> imposed
>> > by law.
>> In fact, it is often the case in this extreme, that the customer's data
>> must
>> live on a different *server* than your other customers' data, not just in
>> a
>> different database.
>> A
>>|||Actually there are laws in place :) I had a heckuva time setting up
software for a client because their data had to be completely separate from
their parent company, due to laws/regulations in financial services. Even
though one was the parent company of the other, they were considered to be
"in competition" with one another, and therefore couldn't share data.
"Aaron [SQL Server MVP]" <ten.xoc@.dnartreb.noraa> wrote in message
news:%23cbaz2OKFHA.1392@.TK2MSFTNGP10.phx.gbl...
>> Thanks for the information. Would you happen to have links with
> references
>> to such laws?
> Personally, I don't know that there are laws per se, but I know that if a
> client wants that (e.g. Fidelity is a prime example), they're going to
> demand it, and you will lose the business if you don't provide it, because
> it is part of their requirement for every vendor.
> --
> Please post DDL, sample data and desired results.
> See http://www.aspfaq.com/5006 for info.
>|||Thanks. I'm very pro on the multiple databases, I'm trying to come up with
solid reasons to argue against an outside consultant that is insisting that a
single database solution is the only right solution.
"Michael C#" wrote:
> I know it's big in the Insurance Industry, although I don't know what the
> specific laws are. It might be part of Sarbanes-Oxley. I would use that as
> a starting point to find out more. Specifically, as far as I know it tends
> to affect the Financial Services sector (including banks, credit unions,
> brokerages, etc.) and it mostly gets into anti-trust law, although I
> wouldn't doubt that other industries like Health Care, etc., might have
> similar laws and regulations.
> "Steve Zohn" <SteveZohn@.discussions.microsoft.com> wrote in message
> news:B68ED433-BB5C-4F2B-9758-524FBDEC1095@.microsoft.com...
> > Thanks for the information. Would you happen to have links with
> > references
> > to such laws? We aren't in a finacial or health care industry, but do
> > deal
> > with goverment funded institutions. And none of our RFC's have referenced
> > this, but I'd like to see some instances where this comes into play.
> >
> > Thanks again,
> > Steve
> >
> > "Aaron [SQL Server MVP]" wrote:
> >
> >> > Also, from a legal standpoint, this may be a requirement in some
> >> industries
> >> > that your clients may be in. I know that in some financial services,
> >> > insurance and other industries, laws for maintaining data integrity are
> >> > pretty strict. In some industries I've even seen where different
> >> > subsidiaries of the same corporation (really big in the insurance
> >> industry)
> >> > can't legally store data in the same databases, due to restrictions
> >> imposed
> >> > by law.
> >>
> >> In fact, it is often the case in this extreme, that the customer's data
> >> must
> >> live on a different *server* than your other customers' data, not just in
> >> a
> >> different database.
> >>
> >> A
> >>
> >>
> >>
>
>

multiple databases for multiple days

I'd like get some opinions on this matter before I go Godzilla in the
next meeting.
My application fills a database during the day, while a webservice
reads from the data. At the end of the day I update statistics,
defrag indexes, do a shrink file and make it read only. Then I create
a new database at midnight and start filling that one. The databases
don't get too large, around 50-100 megs per day. The webservice makes
queries on the older data as well. I choose the multiple database
technique because customers could easily control their data and because
I thought it'd be faster than one large database.
Well, now a sub contractor is cryin' because they need to make
multi-day queries for their reports. They say it'd be too difficult
to do that, and I should just have one db for all of the data. This
is where my newbieness shows. I know there aren't too many specifics
here, but does this request seem absurd? Is it a such a big deal to
do "use db1;select * from table;use db2;select * from table"?Hi
Why separate the data into days? One big DB is a lot easier to manage,
backup and report on than lots of small ones.
This is not the old days of ISAM DB's. One big DB is the way to go.
Regards
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"Johnny Ruin" <schafer.dave@.gmail.com> wrote in message
news:1133479375.134870.146930@.g14g2000cwa.googlegroups.com...
> I'd like get some opinions on this matter before I go Godzilla in the
> next meeting.
> My application fills a database during the day, while a webservice
> reads from the data. At the end of the day I update statistics,
> defrag indexes, do a shrink file and make it read only. Then I create
> a new database at midnight and start filling that one. The databases
> don't get too large, around 50-100 megs per day. The webservice makes
> queries on the older data as well. I choose the multiple database
> technique because customers could easily control their data and because
> I thought it'd be faster than one large database.
> Well, now a sub contractor is cryin' because they need to make
> multi-day queries for their reports. They say it'd be too difficult
> to do that, and I should just have one db for all of the data. This
> is where my newbieness shows. I know there aren't too many specifics
> here, but does this request seem absurd? Is it a such a big deal to
> do "use db1;select * from table;use db2;select * from table"?
>|||Well, I thought the seperate dbs would be faster. What happens in a
year, when the db is 24 gigs? It seems strange to think that it
wouldn't be significantly slower than a 50 meg db.|||Presumably at some point you will be removing the old data -otherwise this
thing will just keep on growing?
If not then in a few years you will have *hundreds* of seperate databases,
then some requirement will come along that means you need to change the db
design, (it will happen) and you will have a real problem keeping them all
in step.
Appropriate indexing can mean that all in one db can perform well.
I suspect the reason they are crying is how is the report meant to know
which dbs to hit - they will have to dynamically build the sql to use each
db in turn, and that list is growing. What happens if the report starts at
11:55 and finishes at 00:05 - a new db has popped into existence in the
middle.
24Gig is not an issue, provided you index correctly, If you ppst the DDL for
the tables together with some typical queries someone is sure to suggest
various options. Also I'd look at the index tuning wizard on frequent
queries. Raw size will only really affect things if you are scanning large
tables.
Mike John
"Johnny Ruin" <schafer.dave@.gmail.com> wrote in message
news:1133493073.595944.279090@.o13g2000cwo.googlegroups.com...
> Well, I thought the seperate dbs would be faster. What happens in a
> year, when the db is 24 gigs? It seems strange to think that it
> wouldn't be significantly slower than a 50 meg db.
>|||Thanks for your comments, fellas. I'll reconsider my aproach.|||Johnny Ruin wrote:
> Well, I thought the seperate dbs would be faster. What happens in a
> year, when the db is 24 gigs? It seems strange to think that it
> wouldn't be significantly slower than a 50 meg db.
24 GB is a small database. At that size, good indexing will certainly
have much more impact on performance than partitioning the data will.
David Portas
SQL Server MVP
--|||So, would you guys see any benefit to doing tableMMddYYYY, or would you
just go with one table period?|||Johnny Ruin wrote:
> So, would you guys see any benefit to doing tableMMddYYYY, or would you
> just go with one table period?
I'd certainly go with one table unless there was proven evidence of
some benefit from partitioning - that probably means for larger data
sets than you are talking about here. I definitely would never go for
partitioning of 50-100MB per table per day. That would just be totally
insane, and probably even damaging to performance - depending on how
the data is used.
David Portas
SQL Server MVP
--|||I would DEFINITELY not use table names with a naming convention of MMddYYYY
as it is ambiguous.
Horizontal partitioning on a daily basis sounds excessive and will (I think)
give you the same reporting problems you face with a seperate db per day.
I would start with the intention of a single table, then IF it causes
problems artificially split it based on a date range, define appropriate
constraints on each newly created table, and a union view across them so the
app still thinks it has one table. That way you are logically maintaining a
single view of the data and hiding your physical tweaks that are only there
for performance reasons.
Mike John
"Johnny Ruin" <schafer.dave@.gmail.com> wrote in message
news:1133535121.678475.286050@.o13g2000cwo.googlegroups.com...
> So, would you guys see any benefit to doing tableMMddYYYY, or would you
> just go with one table period?
>

Multiple Apps on Single SQL Server?

Question for the SQL experts.
We are installing new 2 - BL20p 3.6Xeon 1 - BL40p 3.0Xeon servers and
I wanted to know others opinions as to how to configure the SQL
databases.
Here are the applications that we will be loading. Sharepoint Portal
(125 users), Project Server (50 users) and SQL 2000.
The usage on these apps will not be heavy so can I consolidate all
databases to 1 server without any negative performance? Or should I
install SQL on BL40p and Sharepoint Portal and Project on another
server?
I am fairly new at SQL and I wanted to try and consolidate if possible.
Will a single instance be fine for all 3 apps?
Your thoughts?? I got confused by your question.
Yes, you can consolidate all databases (at least those you mentioned)
to one MSSQL backend (whether you like to set it as one instance or
multiple instances).
No, it is better to have a dedicated server as a sorely Database Server
(MSSQL in this case), which separate from the application server(s).
It will be better to have Portal and Project install on its own server
as a application server but the databases stores in a separate
dedicated MSSQL Server.
Hope it helps.
Mel