The limitations (unexpected) of SharePoint 2010 and/or the way that the "views" work in the ArcGIS for SharePoint create severe performance limitations. SharePoint Views are currently used to filter data. These were created for 2 reasons: To limit the number of records that are retrieved; and to limit the attributes retrieved to a minimum. It appears that the View concept in SharePoint (or ArcGIS for SharePoint) ignores these limitations, causing ALL data to be retrieved. The following re-factor should be considered:
Reduce the main table to only the bare minimum of columns and consider "lifting" some values out of the raw XML where needed (e.g. Earthquakes have structured parameter data in the XML that is useful for filtering).

MAIN TABLE (just the basics for position, title, short description, event type, severity - and???)
  • RawXML - child table for XML-based information (raw Entry, CAP Alert, HAVE in future).
  • Attachments - MIME-types (limited to some configuration)

There may be a need to consider an ACTIVE and IGNORED tableset that is use for performance. This would mean that any items that are set to ACTION or MONITOR would be in the ACTIVE table and others would be in the IGNORED. This de-normalization approach adds complexity but given the severe limitations of the underlying system (SharePoint + ArcGIS) this may be unavoidable.

QUESTION to DEV TEAM: If there is a relationship here can a filter be applied to a sub-List? In the case of a CAP Alert with <parameter> data (e.g. Earthquakes Canada) we need to be able to test on the values in the CAP...

Last edited Jun 24, 2013 at 11:57 AM by cloop, version 1


No comments yet.