When would you want to use ArcSDE (available as ArcGIS Server Basic license level) versus a spatially enabled database?
What are the trade-offs on either side?
What are the benefits on either side?
-
1What used to be the ArcSDE product is now called ArcGIS Server Basic and comes in either Workgroup or Enterprise editions.– Chris MCommented Jul 23, 2010 at 13:09
Add a comment
|
3 Answers
SDE [ArcSDE] can refer to at least two things: the organization of your data in the database (the SDE Schema) or a service listening for connections from clients (the SDE service). Generally they go hand in glove - the SDE service is bound to an SDE schema in a database.
In its "purest" (or perhaps dirtiest) state, SDE handles all of the spatial computations, and only stores data in your database as BLOBs and other native SQL types. Some database functions, like text or XML indexing, are used to improve performance, but generally the database doesn't "know" it is serving spatial data. There's just a bunch of tables and views and procedures, and they're full of data and functions.
With a spatially enabled database, the database IS aware that the data has a location. So, you can put location queries right into your SQL statements. Perhaps this is a good thing for you, it really depends on who is consuming your data. If your data consumers are fluent in SQL it's great! If your data consumers are fluent in ArcMap they could probably care less.
More recently we have been able to blend the two, by using SDE to translate to an underlying native spatial type. Furthermore, we can use "direct connect" to bypass the SDE service and just have the consumer application (ArcMap, ArcGIS server, etc) connect straight to the database. Personally I have had varying levels of success with direct connections.
Benefits to using ArcSDE:
- Seamless integration with ESRI clients
- Good performance
- Some underlying database functionality can be exposed (spatial views, indexes)
Drawbacks to using SDE:
- Can be difficult to recover from corrupted data
- The license is bound to the database
- No easy access to geometry without using ESRI software
Benefits to a spatially enabled database:
- Data easily accessible to any SQL client
- Data can be managed using existing DB tools (backup, restore, analyze)
- Open formats available
Drawbacks to using a spatially enabled database:
- Clients (software) may not be able to connect directly to your data, and may have to use inefficient protocols or exports to see it
- Spatial References are sometimes hard to apply or keep consistent
- Could incur extra configuration or management overhead
I have more experience with plain SDE so there are likely more points for the spatially enabled database.
Hope this helps!
-
1You would be infringing on ESRI licensing if you access the data directly and not through the SDE service. Commented Jul 23, 2010 at 22:07
-
10There is no infringement. ESRI direct connect uses no SDE service (at least at the server end). Moreover, they have published many articles on using PostGres, MSSQL, and WKT as the spatial storage type while using SDE which allows you to communicate with the spatial data directly. And more then once I have had to clean up SDE by accessing data directly when it broke. Another benefit to spatially enabled databases is that the database can do the work rather than bringing all the data into a client and having it do the work.– westyvwCommented Jul 27, 2010 at 0:09
-
3
-
-
2re: spatial references, I think that it is the opposite. Spatial references in PostGIS are standard and the SRIDs are the same as EPSG codes for applicable SRS. With SDE, at least at 9.3x, the SRIDS incorporate extents, etc. so you may have two different SRIDs for the same Spatial Reference System. This causes issues if you want to use spatial SQL.– DavidFCommented Mar 30, 2011 at 18:05
Here's my one line answer: Use SDE when you need multi-user access to your geospatial data.
Let's say you want multiple users to edit your data: use SDE. Let's say you want to serve data to and allow it to be edited over the web: use SDE. If you're a small shop, with one GIS guy, don't use SDE.
If you're the only person using your spatial data, SDE isn't for you. If you don't need multi-user editing, SDE isn't for you. You're better off using a file GeoDatabase.
As for trade-offs...SDE is not trivial to set up or manage. You have to use a RDBMS.
SDE is meant for larger organizations where one database is needed but several users need to access and update/edit data.
answered Aug 7, 2010 at 5:48
-
1I mean Arc products is quite bad when it comes to multi-usr environments. There seems to be a lot of things taht can't be done while people are connected. If performance and robust multi user environment is important there have to be better letting the RDBMS do all the work not involving some dirty middle ware just slowing things down and putting locks on everything. But it looks fancy I have to admit, the box I mean :-) Commented Jan 13, 2011 at 11:07
-
2I agree with Nicklas. Your comparison makes sense within the Arc world, but SDE is not great with multi users. A spatially enabled RDBMS like PostGIS has advantages in this arena. Have you ever tried to grant a user rights to a SDE data set that someone else is viewing?– DavidFCommented Mar 30, 2011 at 14:31
-
Yes, I've run into the issue you're describing with granting privileges. Not sure if it's still a problem as I haven't had to administer an SDE GDB in a couple of years. Grants should not be blocked by locks. How does postgres/postgis deal with multi-user editing? Commented Mar 30, 2011 at 18:31
Nowadays most spatial dbs allows multiple spatial columns in one tables, while SDE sticks to one spatial column for one table. They also have spatial data integrated with their flexible and powerful data management tools, which SDE lacks, such as user sachems, data replication, SQL support and etc.
ESRI SDEBinary is the fast performer. If it comes to ST_GEOMETRY, SDE may not have the best performance.
