One strong point toward this suggestion; when views are nested, the query optimizer will have more difficulty properly identifying and using indexes on the underlying tables, causing significantly less efficient queries. However, views can be incredibly useful in encapsulating code and keeping code redundancy to a minimum.
To that end, having the ability to expand views in place would be tremendously helpful in creating speed-optimized code while still being able to write much shorter code up-front.
In an ideal world, this could be coupled with some kind of a "Smart Alter" functionality for views that would go back and edit expanded view code within other objects to match changes to the base view, even if the view isn't directly referenced as a view. This would certainly be tricky, but searching for exact matches of view text could be a start, maybe using some kind of Red Gate specific text flag (--VIEWMATCH dbo.MyView) or something could also work?
One strong point toward this suggestion; when views are nested, the query optimizer will have more difficulty properly identifying and using indexes on the underlying tables, causing significantly less efficient queries. However, views can be incredibly useful in encapsulating code and keeping code redundancy to a minimum.
To that end, having the ability to expand views in place would be tremendously helpful in creating speed-optimized code while still being able to write much shorter code up-front.
In an ideal world, this could be coupled with some kind of a "Smart Alter" functionality for views that would go back and edit expanded view code within other objects to match changes to the base view, even if the view isn't directly referenced as a view. This would certainly be tricky, but searching for exact matches of view text could be a start, maybe using some kind of Red Gate specific text flag (--VIEWMATCH dbo.MyView) or something could also work?