This is a follow up of ALTER VIEW drops Index from View question.
The accepted response indicates that ALTER VIEW will automatically drop any defined indexes.
This is somewhat counter intuitive to how other similar operations are happening:
- it is natural to expect for related things such as permissions or indexes to be dropped on object drop not on alter
- altering a table does not drop any index (actually you have to drop things like indexes, constraints etc.)
I am wondering about why having this behavior by default in the first place (i.e. is there any objective aspect like performance reduction in some cases due to view alteration).
Question: What is the rationale of dropping all indexes for an altered view?
Best Answer
Kendra Little lays out some good theories for why this happens in her recent blog post: Altering an indexed view in SQL Server drops all indexes
Altering the view could completely change the structure of the data - number of columns, number of rows, the size of the rows, etc. So basically the table would need to be dropped and recreated anyway.
I find the second point, about how likely a change is to run afoul of the indexed view restrictions, to be particularly compelling.
Like Kendra mentions later, and others have mentioned in the comments here, it would be nice if one were simply blocked from altering indexed views. But that change will likely never happen due to backwards compatibility concerns.