ArcSDE由于是使用标准DBMS作为数据的存储引擎，在理论上具有无限的数据存储能力，因此用户不必再将数据进行分割（这也是目前整理基础地形库的一个比较麻烦的问题），而是在一个连续的坐标域内存储所有的要素（9.2由于使用了更长的位数，使得这种存储范围能力真的达到了无限的地步）。

ArcSDE是基于不同类型的DBMS采用的不同空间索引建构方式，我们知道，在数据库中建立索引后，查询速度可以得到有效的提高。一般情况下，我们遇到的ArcSDE的索引都是多层次Index Grid的方法。即对一个要素类建立三级的Grid Index记录，请注意看我们新建一个要素类时Geometry中的属性，会有Grid 1、Grid 2和Grid 3三个参数，其中一般只建立了一个Grid。所谓Grid Index是人为将整个范围的要素类根据Grid的参数划分为N个网格，然后在Schema表（S表）中记录处于这个网格内的要素，如下图：

 在数据库中是由一个到多个表来构成一个逻辑上的要素类，因此，我们有必要介绍一下这些DBMS中的辅助表：

• Business Table——这个表在逻辑上表现要素类和用户“看到”的内容，用户不必去关注其它构成要素类的表集的存在，我们可以认为所有必要的数据都存储在这个表中，包括几何内容。 
• Feature Table——即F表，它存储一个要素类Geometry字段的一些辅助元数据，这些数据可以为将来的图层显示使用。这些表以f开头，如f110，即一个ID为110的要素类的要素元数据表。 
• Spatial Index Table——即S表，存储一个B表的Geoemtry的空间Grid Index。注意，如果不使用Grid Index进行空间索引的DBMS，是不存在F表和S表的。 
• Delta Table——如果一个要素类参与了多版本，则就会出现Delta表，这种表有两种类型，即a表——add table，用于记录被添加的要素类和d表，用于记录被删除的要素类。 

如果是在ArcSDE中储存栅格数据，则会添加一些元数据表，诸如SDE_RAS_、SDE_BND_、SDE_AUX_和SDE_BLK_。

我们许多人在安装ArcSDE后便直接开始使用sde帐号进行数据的存储访问，其实这样的做法非常不好，首先系统维护表GDB_和数据表混杂，其次物理文件也是同一个不利于文件的安全，且在用户控制上也不好。虽然这一切我们在ArcGIS的程序中根本看不出来。我个人的做法是，在建立了sde用户后，使用这个帐号在Oracle中建立一个新的用户，并使用独立的存储文件，我们在使用ArcCatalog时，完全可以使用新建的帐号去访问。这样，在sde用户下全是系统维护表，而在新用户下，纯粹是数据表。