Good or Bad Idea? Multiple Tables for Data Import

Hello all,
We have an application which runs on a campaign basis. Data is loaded
throughout the day into our application. We typically load 20K - 30K rows
of data per campaign per day (total of about 150K - 200K row of data per
day).
We typically run about 30 - 35 campaigns simultaneously.
In order to increase the performance of our application, I was thinking of
loading each campaign into it's own table. The campaign tables would all be
identical. This would allow us to index each of these tables before each
campaign run to ensure the best possible performance.
What do you guys think?
We're finding that our application is being bogged down - we need to query
the tables continously as the application run... and return record sets
with minimal time.
Thanks.
Lucas Tam (REMOVEnntp@.rogers.com)
Please delete "REMOVE" from the e-mail address when replying.
Newmarket Volvo Sucks! http://newmarketvolvo.tripod.com
Lucas
Have you read "Partitioned View" article in the BOL? If I understood you
correctly , that what you need .
"Lucas Tam" <REMOVEnntp@.rogers.com> wrote in message
news:Xns96D12EDD5C9ECnntprogerscom@.127.0.0.1...
> Hello all,
> We have an application which runs on a campaign basis. Data is loaded
> throughout the day into our application. We typically load 20K - 30K rows
> of data per campaign per day (total of about 150K - 200K row of data per
> day).
> We typically run about 30 - 35 campaigns simultaneously.
> In order to increase the performance of our application, I was thinking of
> loading each campaign into it's own table. The campaign tables would all
> be
> identical. This would allow us to index each of these tables before each
> campaign run to ensure the best possible performance.
> What do you guys think?
> We're finding that our application is being bogged down - we need to query
> the tables continously as the application run... and return record sets
> with minimal time.
> Thanks.
> --
> Lucas Tam (REMOVEnntp@.rogers.com)
> Please delete "REMOVE" from the e-mail address when replying.
> Newmarket Volvo Sucks! http://newmarketvolvo.tripod.com
|||"Uri Dimant" <urid@.iscar.co.il> wrote in
news:#O9$T2QuFHA.2076@.TK2MSFTNGP14.phx.gbl:

> Lucas
> Have you read "Partitioned View" article in the BOL? If I understood
> you correctly , that what you need .
Thanks URI, that seems to be what we need.
From your experience, would we gain a lot of performance by segmenting data
into it's own table?
Lucas Tam (REMOVEnntp@.rogers.com)
Please delete "REMOVE" from the e-mail address when replying.
Newmarket Volvo Sucks! http://newmarketvolvo.tripod.com
|||Hi
Yes, if you have appropriate indexes defined on the table you will be
benefit from performance.
"Lucas Tam" <REMOVEnntp@.rogers.com> wrote in message
news:Xns96D180999FD22nntprogerscom@.127.0.0.1...
> "Uri Dimant" <urid@.iscar.co.il> wrote in
> news:#O9$T2QuFHA.2076@.TK2MSFTNGP14.phx.gbl:
>
> Thanks URI, that seems to be what we need.
> From your experience, would we gain a lot of performance by segmenting
> data
> into it's own table?
>
> --
> Lucas Tam (REMOVEnntp@.rogers.com)
> Please delete "REMOVE" from the e-mail address when replying.
> Newmarket Volvo Sucks! http://newmarketvolvo.tripod.com