We recently upgraded our SDE database to 10.1 and in 10.1, the SQL Geometry is the default Geometry type as defined in the DBTUNE table and as such new feature classes used the SQL Geometry Type unless specified otherwise. Also, new Geodatabases use SQL Geometry as the default as well.
What is the reason that the SQL Geometry is the default type in ArcSDE 10.1? Is it to make the Geodatabase more accessible in an enterprise? Are there performance benefits?
Is the parcel fabric supported use SQL Geometry?
Are ArcGIS Topologies supported using SQL Geometry?
I like the capabilities that SQL Geometry offers in terms of accessing the data, but in our situation, the Geodatabase is for data creation and management and I am wondering if the SDE Binary Geometry Type is suitable.
I can't say if there are any "benefits" in terms of performance or so (but most likely minor, SDEBINARY was and is efficient too), but from a functionality point of view, ESRI always strived with ArcSDE and ArcGIS to make the user experience uniform and GIS functions almost completely independent of underlying database storage format and storage options.
This means you should be able to do, from a functionality point of view, exactly the same things (e.g. create topologies) whatever database storage options you choose.
There just seems to be a minor caveat to this when choosing OGCWKB as the geometry storage format, as this Help page states it only supports 2D geometries, which would definitely impact the user experience at some point, but this is a real exception:
"Note that the OGC well-known binary representation supports only simple 2D geometries."
In choosing the data storage type for our enterprise deployment, ESRI assured us that each type would support any stated functionality (FWIW).
What I will say next is just an item that you may want to look into more. I'm not sure why the 'default' type is SQL Geometry (sort of counter intuitive to me), but we initially configured our (2012) DB with that type and had very poor performance. We tried updating the spatial indexes to no avail...our express instance was faster. So ESRI tech support informed us that this was a known issue for MS SQL 2012 and we shifted our storage type to SDE Binary and things were much (much!) faster. I am failing to recollect whether or not the following patch had been applied before or after http://support.esri.com/en/downloads/patches-servicepacks/view/productid/67/metaid/1954 but you may have already. I have read anecdotal evidence that the patch had not helped people until they shifted storage type, so I'd be curios to know what your current performance is like.
I'm not 100% sure if you will find the above information beneficial, but I figured it should at least be passed along.
