partitioned views in sql server 2005 question

Hi,
We have table which should keep only 1 year of data (probably around 200GB).
We want to partition it (by month), however since we have sql server 2005
standard edition, we cannot implement partitioned table.The only remaining
solution would be to use partitioned view.
Since this table is going to be accessed (selects/updates/inserts/deletes)
using partitioned view, my concern is will database engine be able to
handle&use underlaying tables indexes in efficient way (or it will have to g
o
through all indexes, one by one)?
Any ideas, comments?
Pedja"Pedja" <Pedja@.discussions.microsoft.com> wrote in message
news:5C29F55B-83C3-4688-87B8-8E4E98F396CF@.microsoft.com...
> Hi,
> We have table which should keep only 1 year of data (probably around
> 200GB).
> We want to partition it (by month), however since we have sql server 2005
> standard edition, we cannot implement partitioned table.The only remaining
> solution would be to use partitioned view.
> Since this table is going to be accessed (selects/updates/inserts/deletes)
> using partitioned view, my concern is will database engine be able to
> handle&use underlaying tables indexes in efficient way (or it will have to
> go
> through all indexes, one by one)?
Well, that's pretty much why table partitioning was added. Indexed views
don't do a great job of hiding the underlying tables.
For simple selects you can go aginst the indexed views, but for complicated
selects and bulk queries you may have to go against the underlying tables.
David