In theory, the LONG RAW storage used with SDEBINARY should be about the same as the BLOB space used by ST_GEOMETRY, except:
- The storage requirements are in different tables (and, potentially, tablespaces)
- LOBs have the option of both inline and out-of-row storage (and the out of row storage can be targeted to a different tablespace)
- ST_GEOMETRY always uses HIGH precision, so it will be larger than an equivalent shape stored in BASIC (or HYBRID) precision
- Modern default coordinate references use a precision which significantly increases storage over data stored in earlier-generated geometries (higher precision increases the magnitude of the vertex deltas, which increases the bits needed to store vertices)
- In-situ migration requires significant additional storage (which is preserved by the table high-water mark), and is likely to fragment the table (increasing storage and hurting query performance.
Given the state of modern disk storage, you could probably store ten times the previous vector data in under $120 of disk (and it might have a faster seek time), so shoehorning datasets into disk shouldn't be a major concern.
Best practice would be create a new table in a new tablespace (tablespaces, if you consider indexes), taking the opportunity to spatially defragment the table(s) by using the Sort (Data Management) tool to optimize the draw performance by using a UL spatial sort option (Advanced [ArcInfo] license only) when populating the new table (Standard and Basic licenses would need to use a spatially correlated attribute, like zipcode, or mgrs, or geohash, or an index grid id to achieve spatial defragmentation).
- V
