- When you use SSMS to make a "view that includes a spatial column", why would it not be interpreted as a "spatial view" (confusion in terms)?
- When the CreateDatabaseView_management tool was introduced, why would an end user not think "I can use this tool to make a spatial view", when it actually gets interpreted in ArcGIS as a query layer?
- Why can views created using SSMS or CreateDatabaseView_management not be registered with the GDB (and hence store feature type, extents, description/metadata, etc.)?
ArcGIS 10.1+ has seen much of the command line tools become GP/GUI tasks, but creating actual spatial views is one are where ESRI needs to focus.
Since there is indeed a speed difference between spatial views and query layers,
but views are much easier to manage using SSMS, our approach has been to make a "dummy" spatial view using command line, then modify the view definition in SSMS.
We've also seen a speed difference between spatial views built on feature classes stored in the default Geometry spatial type (slower) versus SDEBINARY (faster).
They certainly can be registered with an enterprise geodatabase, if you a) have an enterprise
geodatabase, and b) choose to do so.
Query Layers are a way of accessing spatial databases without ArcSDE..
It's not just spatial views, it's all tables which involve GEOMETRY/GEOGRAPHY objects, but these are an aspect of Microsoft's database implementation (and the difficulty of tuning it), not anything Esri has control over.
I would say the next focus should be on registering views, not creating them.
Wait right there -- This is the key misunderstanding. Query Layers are a way of accessing
spatial databases without ArcSDE. There is no correlation between views and
Query Layers, other than that they need to be spatial to be rendered.
They certainly can be registered with an enterprise geodatabase, if you a) have an enterprise
geodatabase, and b) choose to do so.