I view ArcSDE (and its predecessor, SDE) as something of a seminal technology. In my quest for true enterprise integration of GIS, ArcSDE
fills filled a crucial gap by providing the ability to store, manage and analyze spatial data in the same RDBMS used for everything else. Long gone are the days when I had to manage relates between INFO tables or shapefiles and that’s a good thing. I have since accomplished similar tasks with PostGIS and Oracle Spatial but SDE was the first product I ever used that offered the capability to bring my GIS in from the cold.
At version 9.3, ArcSDE will support PostgreSQL as a back-end, meaning you don’t also need to license an expensive RDBMS in addition to ArcGIS to take advantage of everything ArcGIS Server has to offer. This gives us another option and options are good.
I have blogged before about my involvment with zigGIS, which has given me a lot of exposure to PostGIS. I’ve also done a good bit of work with Oracle Spatial. Both experiences have given me experience with, and a love of, spatial SQL (as each has implemented it). Having all of the data types and methods necessary to store, manage and analyze spatial data completely encapsulated in the RDBMS is a huge advantage. Building an n-tier or services-oriented system is so much easier because all I really need to interact with my spatial data is an OLEDB provider (we’re a .NET shop). This encapsulation serves to further expose the disadvantages of the current middleware approach of ArcSDE.