I would like to add my 2 cents to this post based on my experiences of the past few days.
In the past i relied heavily on sde views - take a spatial table, create a view on it, register that with sde using the command line tools and then modify the sql of the view to join in several other, non-spatial, tables.
The resulting 'sde view' is seen by esri in the same way a feature class would be.
This is a very effective tool and we use it extensively.
At 10.1, the idea was that sde command line tools are being mothballed. 'Most' everything you need to do will be available in Catalog, ArcMap and/or python.
Well that is not entirely true in the case of spatial views.
At 10.1 you can make a spatial view in ArcCatalog and it works great. So we did that, and we based ags services on map layers based on those views. Then a few days ago we started seeing issues. The services failed. ags error logs stated that ags could not recognize the geometry type of the layers in those services.
The issue is that our data expires over time and we remove it from the view via a sql where clause. When that view is empty ags/sde no longer recognize it as being a view - it is just a table. So our view sql may say the value in some field must be less than 4 hours old. If no data is added to that table over 4 hours it will be empty. The service will fail and our app throws errors. Not good.
The answer we are getting now is to use the command line tool to create the views and make sure they are registered with sde.
Apparently with the new style views the geometry metadata is gathered on the fly from the first record in the table.
That makes sense to me. But what about when there are no records? Seems like a better system would have been to get the metadata from the only spatial column in the view - the one in the base table - which is a feature class. A feature class can be empty and sde/ags still knows it is a feature class.
Anyway, sde command line is not ready for the closet yet.