| Message |
Actually, SDEBINARY *does* only use LONG RAW, and it's been
consistently faster than the LOB storage form (SDELOB storage),
mostly because the LOBs are slower than LONG RAW. Of course,
that's not an option at 11g, and even some 10gR2 sites have
Oracle issues with LONG RAW reliability.
All three forms (SDEBINARY/SDELOB/ST_GEOMETRY) use the
same basic internal format for the geometry (using integer
compression). The ST_GEOMETRY difference is on the custom
index-organized table for the spatial index, as well as the
ability to store the geometry in the business table row
(vice the external F table).
It's hard to make a generic comparison between *all* data
in a specific format, but ST_GEOMETRY has often been close
to SDEBINARY performance, for all that it's based on LOB
storage.
Then again, the coordinate reference parameters used have
the same or larger impact as changing storage methods --
The research below indicates that changing the coordref
and storage method for 1218Mb of US "Data and Maps"
shapefiles (59 files) into ArcSDE can cause overall
storage in Oracle 10gR2 with ArcSDE 9.2 (SP6) to vary by
one third, but that keeping ~11cm precision in either
BASIC or HIGH layer precision with ST_GEOMETRY actually
uses less total space (in 1Mb extents) than the old
BASIC storage standard for WGS84 geographic data.
- V |
| |
Storage X/Y Coordref Precision -aall -anone Total% Geom%
SDEBINARY -210,-120,1000000 BASIC 1339 1261 - -
SDEBINARY -210,-120,1000000 HIGH 1339 1261 0.0 0.0
SDEBINARY -400,-400,1000000000 HIGH 1540 1464 15.0 16.1
SDELOB -210,-120,1000000 BASIC 1585 1509 18.4 19.7
SDELOB -210,-120,1000000 HIGH 1588 1509 18.6 19.7
SDELOB -400,-400,1000000000 HIGH 1826 1748 36.4 38.6
ST_GEOMETRY -210,-120,1000000 BASIC 1309 1224 -2.2 -2.9
ST_GEOMETRY -210,-120,1000000 HIGH 1313 1224 -1.9 -2.9
ST_GEOMETRY -400,-400,1000000000 HIGH 1548 1461 15.6 15.9
|