パーソナルジオデータベースは、ファイルジオデータベースよりもインデックス付き属性の迅速なクエリに適していますか？

データをクエリして住所を検索するArcGIS Engineアプリケーションのデータを準備しています。ストリート名フィールド、家番号フィールド、またはその両方で検索する場合があります。パーソナルジオデータベースまたはSDEジオデータベースを使用する場合、単一列インデックスに加えて複数列属性インデックスを追加できます。何らかの理由で、属性インデックスの作成に関するESRIの記事によると、ファイルジオデータベースを使用する場合、複数列の属性インデックスは使用できません。なぜそうなのか、彼らは言及していません-ファイルジオデータベースは何らかの理由でそれらを必要としないのでしょうか？

家番号フィールドと街路名フィールドの複数列インデックスは、両方のフィールドを一度に検索するときの理論上のクエリパフォーマンスを理論的に改善するはずですが、パーソナルジオデータベースの使用に切り替える価値はありますか？パーソナルジオデータベースを使用すると、マルチカラムインデックスの利点が損なわれる可能性があると感じています。

私は、Esriがパーソナルジオデータベースからの移行を望んでいるという印象を受けてきましたが、これはパーソナルジオデータベースの方が適している場合ですか？これに関する経験がある場合、私は知りたいです。

あなたの質問の最初の部分に答えるには、マルチカラムインデックスに関する属性インデックスの作成ヘルプファイルの追加テキストを見ると役立つと思います。

複数列インデックスにフィールドが表示される順序は重要です。列Aが列Bの前にある複数列インデックスでは、列Aを使用して初期検索が行われます。また、このようなインデックスは、列Bのみを含むクエリの場合よりも、列Aのみを含むクエリの場合にはるかに役立ちます。
AとBに複数列のインデックスを作成します。通常、このインデックスは、両方の列を含むクエリの場合により効率的です。Aのみを含むクエリの場合、このインデックスはAのみのインデックスよりも遅くなります。このインデックスは、Bのみを含むクエリにはほとんど役に立ちません。これを補うために、Bに追加のインデックスを作成できます。

これらのパッセージは両方とも、マルチカラムインデックスが特殊な用途に適していることを示しています。さらに、そのようなインデックスを使用して、含まれている列の1つだけでソートすると、実際にパフォーマンスが低下する可能性があります。このため、複数列のインデックスに含まれる属性ごとに個別の列インデックスが必要になる可能性があります。

個人的なGDBよりもファイルを選択する9つの理由を示す、古くて面白いドキュメントへのリンクをESRIが見つけました。興味深いのは、パフォーマンスを1つの理由として明確に呼び出していることです。このパフォーマンス向上の一部は、ファイルベースのストレージシステムによるものです。これは、複数列のサポートの欠如にもつながる可能性があると思います。単一のファイルである個人用GDBとは異なり、ファイルGDBのインデックスはGDB構造内に個別のファイルとして保存されます。これは、特定のフィーチャクラスのインデックスファイルと属性ファイルを一緒にリンクしてアクセスする必要があることを意味します。マルチカラムインデックスがインデックスファイルと属性ファイルの間を行き来し、インデックスパフォーマンスの向上を上回るパフォーマンスヒットを引き起こす可能性がある場所を確認できました。

File GDBの方がPersonal GDBよりもパフォーマンスが大幅に向上しているため、マルチカラムインデックスを実装する価値はおそらくありませんでした。

両方のタイプのGDBを扱った私の経験では、Personal GDBがファイルよりも約50％大きく実行されています。File GDBに関して提供したデータに基づいて、PGDBに変換する場合、おそらく最大300MBのPersonal GDBになります。私が見たところでは、ESRI製品内と個別の両方でMS Accessデータベースを操作すると、「。mdb」ファイルのサイズが100MBを超えるとパフォーマンスが低下し始めます。

もう1つの問題は、属性検索を高速化できたとしても、データフレーム内の移動とビューの更新に関連する大きなパフォーマンスヒットが発生する可能性があることです。PGD​​B内にある場合、レイヤーは単純に速く描画されません。ジオデータベースのタイプを比較するこの記事では、パフォーマンスの違いについて詳しく説明します。

多くのことと同様に、最良の選択は最終的にはユースケースが何であるかを要約します。クエリや更新など、Accessインターフェイスで実行できるデータベース固有の操作が多数ある場合は、Personal GDBの方が適している可能性があります。クエリを実行するだけで、主に空間データを視覚化する場合は、パフォーマンスは間違いなくFile GDBの側に落ちます。

パーソナルジオデータベースではなくファイルジオデータベースを使用することには、少なくとも9つの理由があります。残念ながら、古いPGDBを保持する理由はまだたくさんあります。あなたのジレンマはそれらの一つです。（このトピックに関するESRIの出版物はありません）

FGDBを介したFGDBの主な目的は、複数列の「属性」インデックスやその他の高度なSQL関数などの機能ではなく、ストレージ容量と空間データのパフォーマンス（描画速度、検索、空間インデックス、空間クエリなど）であると考えています通常、そのようなDBMSの不可欠な部分です。（MS AccessベースのPGDBとESRIネイティブFGDBは違います）MS Accessデータベースの最大ファイルサイズ制限は2GBで、これは単一のPGDBの最大サイズでもあります。対照的に、FGDBファイルのサイズ制限は256 TBに1 TBです。

ESRIでは次のことも述べています。SQL式の作成に使用する構文は、データソースによって異なります。これは、SQLは標準ですが、すべてのデータベースソフトウェアが同じSQLの方言を実装しているわけではないためです。およびファイルジオデータベースを含むクエリファイルベースのデータ、カバレッジ、シェープファイルには、INFOテーブル、dBASEテーブル、CAD、およびVPFデータは、SQLの方言を使用し、個人で利用可能な機能と機能のサブセットをサポートしているのArcGIS内に実装し、 ArcSDEジオデータベース。

つまり、DBMSの基盤となるジオデータベースがこの機能をサポートしている場合、PGDBとArcSDE GDBはその証拠です。これが、基礎となるMS Accessデータベースを持つPGDBに複数列インデックスを作成できる理由です。この機能をサポートする基盤となるDBMSを備えたArcSDEジオデータベースと同じです。

File Geodabaseに関しては ; で9.2 FGDBリリースESRIはほのめかしこれらの特徴や機能のいくつかは、引用将来のFGDBのリリースで追加されるかもしれません。 「ファイルジオデータベースは、パーソナルジオデータベースで使用可能なすべての機能をサポートしていません。ArcGIS9.2では、ファイルジオデータベースでサポートされていない最も一般的に使用される機能には、DISTINCT、GROUP BY、ORDER BY、および設定関数AVG、COUNT、MIN、 MAXおよびSUMは、サブクエリ以外ではサポートされていません。これらの一部のサポートは、将来のリリースで追加される可能性があります。

4年後のバージョン10では、これらの機能は使用できません。（利用可能な機能のリスト）

FGDBは進行中の作業であり、必要なSQL DBMS機能をすべて必要とするだけでなく、複数列のインデックス作成機能も必要と思われます。ESRI開発者がその機能をFGDBに拡張することが重要であると判断するまで、PGDBに固執するでしょう。

このスレッド/問題を復活させると、可能であればFGDBとPGDBを組み合わせることが有用であることがわかりました。たとえば、スクラッチジオデータベースをPGDBにすると、クエリのパフォーマンスが大幅に向上します。前述のように、PGDBのサイズはあまり大きくしないでください。