Carla;

There are definitely numerous design considerations.

First, the view has to be schema bound. This makes it harder to change any objects the view depends on (you have to remove schema binding first, make the change, and then recreate it). In a mature database where the schema rarely changes this is of limited concern of course, but in a newly created database this can become tedious.

Next, as you said, the index has to be stored on disk. Depending on the size of the table and number of columns involved, this can be quite substantial. Also, it will slow down write operations on the tables involved. In most cases, this will not be a substantial amount, but it can be a consideration for tables that receive a lot of updates.

Then, if you are not in enterprise edition, you have to deal with the complexity of the query hints to actually use the index (this is handled by the engine in Enterprise Edition.) Also, it will add complexity if you use replication and both servers are not in Enterprise Edition (the engine in Enterprise edition will handle almost all of it for you, but in Standard Edition you have to do a lot more of it manually).

In many cases, the advantages to using an indexed view will greatly outweigh the disadvantages, but these are all things that must be considered.