3

I have a bunch of operational tables, some contain spatial data, some do not. In order to fulfill all my operational mapping reports, I will need to have the flexibility to have feature services or dynamic map services that perform table joins and various aggregations on the underlying geodatabase (or client side). All the tables are in the same enterprise geodatabase instance but not all of them are spatial tables (include a geometry column).

What are my various options to do this? So far I have come up with:

  1. Joining and Relating tables (http://help.arcgis.com/en/arcgisdesk...0000002n000000) It's my understanding, however, that feature services do not support data from joined tables (http://resources.arcgis.com/en/help/...00000007000000)
  2. Query layers
  3. Client side Feature Service joins and aggregations
  4. Custom Geoprocessing service (ArcPy) that returns a FeatureSet made up of a custom FeatureClass (input schema?) generated by running the join,aggregation query server-side, creating the custom FeatureClass list and returning that to the client, the idea being that I would make the custom geoprocessing service look like a FeatureService or a Dynamic Map Service to the client.

I'd like to get people's opinions in terms of maximum flexibility and scalability ( I don't want to run into a situation where the client must handle large numbers of records in order to perform client side aggregations and joins, that stuff should be done up front in the server and the aggregated data should be made available to the client. )

  • Joins, relates and queries generally occur on the server side so it depends on your server/load if there is any significant impact on the clients - generally not as the database access is only a small, but vital, part of the client-server relationship. Shifting operations onto the client side may ease the pressure on the server but all the data must be sent for the client to evaluate. Number 4 is a lot of work but offers the best option, populating only the relevant features from the joined table provided number 1 is definitely not an option. – Michael Stimson May 31 '14 at 5:26
  • What I'm trying to do is pick an option that will allow me to execute all the necessary joins to slice, dice, and aggregate the data the way I need to, every example of Map Services and Feature Services assumed the data was coming from 1 feature class, I need an option that allows me to join multiple spatial and non-spatial tables. I don't think #3 is really an option because I'll be dealing with mobile clients so I need to keep the client-side memory consumption as low as possible. – alessandro ferrucci May 31 '14 at 12:44
  • Can you please provide info whether your issue was resolved. It would be very helpful in a similar task I am currently working on. Option 4 is an interesting one and I am curious whether it worked for you and how complicated was at the end of the day. Thank you. – Smalis Oct 16 '14 at 10:14
  • Smalis - I decided to go with SQL joins because they let me use pure SQL which ended up being trivial to implement arbitrarily complicated Dynamic Map Services and allowed the DB to do all the heavy lifting (very good thing!) I chose not to go with ArcPy because I have seen performance issues when you're asking ArcPy to generate many thousands of features on the fly or do spatial analysis, so you may not want to go that route unless other solutions do not offer all the features you need. – alessandro ferrucci Oct 17 '14 at 12:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.