Using of Indexed views for data retrival

Our application has over hundreds of Tables in its SQL Server database. Now we want to give the facility for users to write queries for certain areas and retrieve the data. Because the current database architecture is too complicated, I am planning to create a set of simplified indexed views and expose those views to users to write queries against them.

D开发者_如何转开发ata in the tables are changing very frequently. Is it ok to use Indexed views for such tables? I don't want to make this feature an overhead to the current functionality.

Can you foresee any issue with this procedure?

Thanks!

Any indexed view will add a performance overhead when tables are inserted/updated (inserted/updated data must be persisted to the indexed view as well). Based on your description of your requirement, I would start with a regular view and only consider indexing the view if performance of these user written queries warrants it.

I tested my database with some indexed and non-clustered indexed views. Views with clustered index makes the update/delete operations slower in the underneath tables. But that's happens in millisecond range. I understand it depends on the complexity, but this is what I have observed for my scenario.

I ran a update query which update 15000 records. With indexed view - 550ms -650ms
Without clustered index – 250ms – 280ms

Our database doesn't have 100s of saving per min. So I think indexed views is suitable for our case.

Thanks!