Views are a valuable tool for the SQL Server Developer, because they hide complexity and allow for a readable style of SQL expression. They aren't there for reasons of performance, and so indexed views are designed to remedy this shortcoming. They're great in certain circumstances but they represent a trade-off, and they come with considerable 'small print'. Jes Borland explains.
Prevent overlapping of time events with an indexed view.
Here is some information about an important MERGE “wrong results” bug, involving indexed views, that could be affecting the accuracy of your queries right now, and what options you have for working around the problem.
As databases grow, it often becomes necessary to add new I/O paths to accommodate the growing space. Even without growth that requires this scale, it can still be useful to utilize multiple I/O devices to spread out the load. One way that you can make optimal use of new drives is to add a filegroup to the database and move certain objects (say, all of your indexed views) to the new filegroup.
Here’s a technique that uses a view with a unique index and a dummy table with only two rows to trick SQL Server into enforcing your business rules.
CAN you create AND USE an indexed view in non-Enterprise Editions of SQL Server?