Actually, you NEVER want to build a table indexes before initial load. This guarantees the worst possible load performance, and will fragment the spatial index (which will be sub-optimal, since the index parameters are best derived from the data to be indexed, after it has been loaded).
In reality, shapefiles will often out-perform an enterprise geodatabase table, especially in unbounded queries (draw all rows), just because the database overhead to support ACID can't compete.
Small subset draw performance for ALL data formats always benefits from reorganizing the features into spatial order, though it may be barely measurable with small tables, it's always present, and in large tables is always significant (and in very large tables can have several orders of magnitude of performance gain vice raindomly organized tables.
There are dozens of variables that go into draw performance, so a "What can be done?" question can only be answered, "Well, it really depends." To generate an answer, you'd need to provide:
- The exact RDBMS
- The exact version of ArcGIS (and if different, the version of the geodatabase)
- The exact coordinate reference
- The topology class (point/mpoint/line/poly)
- The storage format
- The number of features
- The average number of vertices per feature
- The average extent of each feature
- An indication of the spatial fragmentation (how far apart the rowids are from each other for each index tile) -- whether the features are sorted on a spatial component like map grid designator or in feature creation order, or randomly over time.
- What steps have been taken to optimize render performance
There are also render rule optimizations (Are the features being drawn by multiple queries?) and other issues that impact draw performance that have nothing to do with storage format.
It also helps to understand that features are NEVER "loaded into SDE". Features are always loaded into the database through ArcSDE components, as embedded in ArcGIS clients.
- V
