Indexed view slows down data insert into contributing table

[PROPAR]

I use SQL Server 2005 Enterprise Edition.

I build an indexed view VIEW_EVENTS joining data beetween a constant table and an EVENTS table with a data input rate of 1000 rows/sec, varchar and int fields.
The view clustered index is on a an IDENTITY int from the EVENT table.

The SELECT request on the VIEW_EVENTS is then efficient, but the INSERTion rate is VERY slow, and SQL Server can't cope with the input rate.
Data are still been INSERTed looong after the feeder produced them.

If I remove the VIEW_EVENTS index (or de-activate it), SQL Server easily keeps the input rate, but the SELECT request on the VIEW_EVENTS is slowed down, four or five times slower, and this is worse as data volume increases.

Is there a way to have it both : an speedy INSERT and an efficient SELECT ?
Gennerally speaking, what is a good SQL Server construction to insure both reading and writing on real-time changing data ?

Thank you for any clue since I'm locked in a loose/win situation.

 

[ptheriault]

No, any indexes you create on the base tables or view that are bound to the base tables will slow down your inserts. It's just the way it is! The indexes must be updated on the inserts. If you are inserting that many records you may consider not having any indexes on that table. Sometimes heaps are good.

- Paul
- If at first you don't succeed, find out if the loser gets anything.

 

[PROPAR]

But I thought that indexes where not updated at every insert, but slowly became less relevant until they were re-computed by a scheduled daily task for example ?