To add another use case:
Feature class is versioned/archived/branch versioned simply to allow offline use in Collector.
Feature class is updated nightly from another database so every night, another row is added for each record to the dataset. The dataset eventually grows extremely large killing performance.
Something similar to the Trim Archived feature class would be ideal.
The below comments were moved from a separate Idea, to more accurately reflect the work under consideration by the development team.
+1 from another developer concerned about database bloat.
The Utility Network implementation I help look after has only been live for about six months and the rows in the branch tables for the subnetline feature classes are already over 100 times the number you see in DEFAULT. This matters a lot as the doing spatial intersects on these are very inefficient due to the subnetwork line extents (a SQL optimiser issue), which makes their map display and using the Find Subnetworks tool incredibly slow.
Also DIRTYAREAS already has over 400,000 rows compared to the ones needing attention in DEFAULT will be well less than 100.
I can't see a useful business case for keeping history for these feature classes in particular for the life of this implementation.
Being able to periodically trim this these will be a necessity sooner rather than later.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.