个人地理数据库是否比文件地理数据库更适合于快速查询索引属性？

我正在为查询数据以搜索地址的ArcGIS Engine应用程序准备数据。有时我们只在街道名称字段，门牌号字段或两者上搜索。使用个人地理数据库或SDE地理数据库时，除了单列索引外，还可以添加多列属性索引。由于某些原因，根据创建属性索引 ESRI文章，使用文件地理数据库时无法使用多列属性索引。他们没有提到为什么会这样-也许文件地理数据库出于某种原因不需要它们？

理论上，一次搜索两个字段时，在门牌号字段和街道名称字段上使用多列索引应该可以提高我的查询性能，但是是否值得切换到使用个人地理数据库？我感觉使用个人地理数据库的缺点可能会抵消多列索引的好处。

我一直以为Esri希望我们远离个人地理数据库，但是在这种情况下，个人地理数据库是更好的选择吗？如果您有任何经验，我很想知道。

为了回答您问题的第一部分，我认为查看“创建属性索引”帮助文件中有关多列索引的其他文本会有所帮助。

字段在多列索引中出现的顺序很重要。在A列位于B列之前的多列索引中，A列将用于进行初始搜索。同样，这样的索引对于仅涉及列A的查询将比仅涉及列B的查询有用得多。
在A和B上创建一个多列索引。对于同时涉及两个列的查询，该索引通常会更有效。对于仅涉及A的查询，此索引将比仅对A的索引慢。该索引对于仅涉及B的查询几乎没有用。要进行补偿，您可以在B上创建一个附加索引。

这两个段落都表明，多列索引更适合于特殊用途。此外，使用这样的索引仅对所包含的列之一进行排序实际上会损害性能。因此，对于多列索引中包含的每个属性，可能都需要有单独的列索引。

我找到了ESRI的一个旧的但有趣的文档的链接，其中指出了选择个人GDB上的文件的9个理由。有趣的是，它特别指出性能是原因之一。这种性能提升的部分原因在于基于文件的存储系统。我认为这也可能导致缺乏多列支持。与作为单个文件的个人GDB不同，文件GDB中的索引作为单独的文件存储在GDB结构中。这意味着特定要素类的索引文件和属性文件必须一起链接和访问。我可以看到多列索引将导致索引和属性文件之间来回跳转，并可能导致性能下降超过索引性能收益。

由于与个人GDB相比，文件GDB已经有了显着的性能提升，因此可能不值得实现多列索引。

在使用两种GDB类型的经验中，我已经看到Personal GDB运行的文件大小大约比文件大50％。根据您提供的有关文件GDB的数据，如果要转换为PGDB，则最终可能会有〜300MB的个人GDB。从我所看到的来看，在ESRI产品中以及单独使用MS Access数据库时，一旦“ .mdb”文件的大小明显增加超过100MB，您就会开始发现性能下降。

另一个问题可能是，即使您可以加快属性搜索的速度，也会看到与在数据框中移动和刷新视图有关的巨大性能损失。如果该层位于PGDB中，则其绘制速度不会那么快。本文比较了地理数据库的类型，可提供有关性能差异的更多信息。

与很多事情一样，最佳选择最终将归结为您的用例。如果您想在Access界面中执行很多特定于数据库的操作，例如查询和更新，则Personal GDB可能会更好。如果您仅计划进行一些查询，而主要是可视化空间数据，那么性能肯定会落在File GDB的一边。

在个人地理数据库上使用文件地理数据库的原因至少有9个。不幸的是，仍然有很多理由可以保留旧的PGDB。您的困境就是其中之一。（没有关于此主题的ESRI出版物）

我相信FGDB优于PGDB的主要目的是存储容量和空间数据的性能（绘制速度，检索，空间索引，空间查询等），而不是诸如多列“属性”索引和其他高级SQL功能这样的功能。通常是任何DBMS不可或缺的一部分。（请注意，不是基于MS Access的PGDB，而是基于ESRI的FGDB。）MS Access数据库的最大文件大小限制为2GB，这也是任何单个PGDB的最大大小。相比之下，FGDB文件大小限制为1TB扩展为256TB。

ESRI还指出：用于构建SQL表达式的语法因数据源而异。这是因为尽管SQL是标准，但并非所有数据库软件都实现相同的SQL方言。而要查询基于文件的数据，包括文件地理数据库，覆盖范围，shape文件，INFO表，dBASE表，CAD和VPF数据，您可以使用SQL的ArcGIS的内实施的话，支持的功能和个人可用功能的子集和ArcSDE地理数据库。

换句话说（如果PGDB和ArcSDE GDB证明了这一点），如果基础DBMS的地理数据库支持此功能，则它应该可用。这很可能就是为什么您能够在具有基础MS Access数据库的PGDB中创建多列索引的原因。与具有支持此功能的基础DBMS的任何ArcSDE地理数据库相同。

至于File Geodabase ; 在9.2 FGDB版本中，ESRI暗示可能在将来的FGDB版本中添加其中某些功能。 “文件地理数据库不支持个人地理数据库的所有可用功能。在ArcGIS 9.2中，文件地理数据库不支持的最常用功能包括DISTINCT，GROUP BY和ORDER BY，以及设置的函数AVG，COUNT，MIN，子查询之外不支持MAX和SUM。将来的发行版中可能会添加对其中一些的支持。

四年后的版本10中，这些功能都无法使用。（可用功能列表）

FGDB似乎正在开发中，它需要多列索引功能，以及它需要所有必需的SQL DBMS功能。我想在ESRI开发人员决定将其功能扩展到FGDB之前，我们将一直困扰于PGDB。

恢复该线程/问题，我发现在可能的情况下将FGDB和PGDB结合起来可能很有用。例如，将暂存地理数据库用作PGDB可以极大地帮助提高查询性能。如上所述，PGDB的大小不应增加太多。