After spending a little time Googling for ArcSDE management best practices, I came up empty handed. I have a good understanding of Spatial Databases and their management having implemented several large scale Oracle Spatial databases, but wanted to get your thoughts on practices or patterns one should adhere to make their life easier, and their spatial holdings usable and secure.

What practices do you employ on your ArcSDE database to ensure integrity, security, and consistency of your ArSDE Instance?

What design goals do you aim for when planning your ArcSDE instance and why?

They are broad questions, and the answer can change significantly with the size, requirements and scope of the implementation, but I would like to gauge the interest in a community based guide for this topic.

locked by PolyGeo Feb 11 '16 at 22:16

This question’s answers are a collaborative effort. If you see something that can be improved, just edit the answer to improve it! No additional answers can be added here.

Read more about locked posts here.


That is actually something you will find little documentation on publicly. There are classes/workshops that ESRI charges for or that you can attend at the ESRIUC but less in the public space.

A couple of the points you mention come out of good DBA practices; but some really dont and really depend on your sytems and needs.

For integrity, for sure a stable hardware platform (I always go clustered systems) is key; and using the right DB backend. I am from a strong state and federal background so I usually stick to big-iron DBs like MSSQL or Oracle. MSSQL2008 spatial gives you a good toolkit for the cost; versus if you really want bullet-proof with 3rd party access you want to consider Oracle; where lots of apps connect to the spatial side.

Security; well there you have a strong DBA need to make sure you have accounts configured properly; but then you also have a need to use the built-in ESRI controls for who can read/write etc from your DBs. This also brings into question the structure of your data and your systems using it; do you need to create higher security silos where you have more tighter user level security; or is just a huge single DB ok with you maintaining the user by user level permissions across the features.

Things you also want to think about is using internal objects like domains versus reference tables with those values good for you; domains may not be accessible from 3rd party apps looking at your data; where a reference table can be joined and you have those coded values.

Data normalization is a big topic to consider; some people are happy doing a solid normalized design with geometry only SDE features and then all the tabular stuff in business tables that you then have a lot of indexes and views to optomize performance for searching by other apps.

So if you have particular areas you are curious about; feel free to add more details to your questions but much of what you looking to really depends on your platform and your functional needs. A high-speed web-app maynot want SDE versus just fGDB; versus dynamic data would demand SDE.

  • I knew asking this question would garner broad ranging answers, as is the nature of the question. Thank you very much for your response. I have my own list of best practices that I've developed over the years based on Database development and administration, though I feel there would be community benefit on a collaborative effort to compile a list based on the topics you have outlined. Would you agree? – OptimizePrime Apr 15 '11 at 13:25
  • Yes, i think so. Maybe the Wiki section could serve as a starting point; even consider looking from Spatial DB's en mass; not just the ESRI/ArcSDE route. There are some differing things you can see for design considerations in a Oracle/Spatial versus what I am doing in my MSSQL2008 system; where I have the MS-Spatial layer just wrapped by ESRI fro some app access; everything else such as Safe/FME talks to the MSSQL direct. That is a deliberate design consideration of my own to reduce dependency on the ESRI layer. – D.E.Wright Apr 24 '11 at 0:58

I think DeWright pretty much hit the nail on the head. The more complex the security strategy you want the more sophisticated you will want your rdbms.

I have always had a desire to build databases with multiple access types. Such as sdo, postgis. Allowing more than one software or IDE to manipulate or display the data.

I would suggest taking the high road and spend extra time in research/test scenarios before committing. Some of these options sound great but have limitations.

Optimization, normalization and solid db design before hand will allow plenty of flexibility (spatially) in the long run.

  • 1
    I am a big believer in a good plan ;) But I continually come across companies that want to implement location intelligence and frown on a well defined written strategy to do so. For me the sweet spot is 'giving the use what they need/want while ensuring data management functions are kept as elegant/functional as possible'. These are the two goals I keep in mind always. – OptimizePrime Apr 15 '11 at 13:35
  • you could spend lots of time on the dbtune file. – Brad Nesom Apr 15 '11 at 14:49
  • The biggest part is your design; if you are needing to building data that will be used in spatial and non-spatial tools you really want to highly normalize your data; seperating out the spatial from tabular. Just to keep your tables cleaner and reduce the amound of stuff you store in that space. – D.E.Wright Apr 15 '11 at 16:36

Not the answer you're looking for? Browse other questions tagged or ask your own question.