Sind persönliche Geodatabases besser für die schnelle Abfrage indizierter Attribute geeignet als Datei-Geodatabases?

Ich bereite Daten für eine ArcGIS Engine-Anwendung vor, die die Daten abfragt, um nach einer Adresse zu suchen. Manchmal suchen wir nur im Straßennamenfeld, nur im Hausnummernfeld oder in beiden. Bei Verwendung persönlicher Geodatabases oder SDE-Geodatabases kann zusätzlich zu einspaltigen Indizes ein mehrspaltiger Attributindex hinzugefügt werden. Aus irgendeinem Grund sind laut ESRI-Artikel Erstellen von Attributindizes mehrspaltige Attributindizes bei Verwendung von Datei-Geodatabases nicht möglich. Sie erwähnen nicht, warum dies der Fall ist - vielleicht brauchen sie Geodatabases für Dateien aus irgendeinem Grund nicht?

Ein mehrspaltiger Index für das Hausnummernfeld und das Straßennamenfeld sollte theoretisch meine Abfrageleistung verbessern, wenn beide Felder gleichzeitig durchsucht werden. Lohnt es sich jedoch, auf die Verwendung einer persönlichen Geodatabase umzusteigen? Ich habe das Gefühl, dass Nachteile der Verwendung einer persönlichen Geodatabase die Vorteile des mehrspaltigen Index zunichte machen könnten.

Ich hatte den Eindruck, dass Esri möchte, dass wir uns von persönlichen Geodatabases entfernen. Aber ist dies ein Fall, in dem persönliche Geodatabases die bessere Option sind? Wenn Sie Erfahrung damit haben, würde ich gerne wissen.

Um den ersten Teil Ihrer Frage zu beantworten, ist es meiner Meinung nach hilfreich, den zusätzlichen Text in der Hilfedatei zum Erstellen von Attributindizes zu mehrspaltigen Indizes zu lesen.

Die Reihenfolge, in der Felder in einem mehrspaltigen Index angezeigt werden, ist wichtig. In einem mehrspaltigen Index mit Spalte A vor Spalte B wird Spalte A verwendet, um die anfängliche Suche durchzuführen. Ein solcher Index ist auch für Abfragen, die nur Spalte A betreffen, viel nützlicher als für Abfragen, die nur Spalte B betreffen.
Erstellen Sie einen mehrspaltigen Index für A und B. Dieser Index ist normalerweise für Abfragen mit beiden Spalten effizienter. Bei Abfragen, an denen nur A beteiligt ist, ist dieser Index langsamer als ein Index nur für A. Dieser Index ist für Abfragen, die nur B betreffen, von geringem Nutzen. Zum Ausgleich können Sie einen zusätzlichen Index für B erstellen.

Beide Passagen zeigen, dass mehrspaltige Indizes für den speziellen Gebrauch besser geeignet sind. Darüber hinaus kann die Verwendung eines solchen Index zum Sortieren nur einer der enthaltenen Spalten die Leistung beeinträchtigen. Aus diesem Grund ist es wahrscheinlich, dass für jedes der in einem mehrspaltigen Index enthaltenen Attribute einzelne Spaltenindizes erforderlich sind.

Ich habe einen Link zu einem alten, aber interessanten Dokument von ESRI gefunden, in dem die 9 Gründe für die Auswahl einer Datei gegenüber einer persönlichen GDB aufgeführt sind . Es ist insofern interessant, als die Leistung ausdrücklich als ein Grund genannt wird. Ein Teil dieses Leistungsgewinns ist auf das dateibasierte Speichersystem zurückzuführen. Ich denke, dies könnte auch zu dem Mangel an mehrspaltiger Unterstützung führen. Anders als in der persönlichen GDB, bei der es sich um eine einzelne Datei handelt, wird ein Index in einer Datei-GDB als separate Datei in der GDB-Struktur gespeichert. Dies bedeutet, dass die Indexdatei und die Attributdatei für eine bestimmte Feature-Class miteinander verknüpft und aufgerufen werden müssen. Ich konnte sehen, wo ein mehrspaltiger Index dazu führen würde, zwischen den Index- und Attributdateien hin und her zu springen und möglicherweise einen Leistungseinbruch zu verursachen, der den Leistungszuwachs bei der Indizierung überwiegt.

Da die Datei-GDB bereits erhebliche Leistungssteigerungen gegenüber der persönlichen GDB aufweist, hat sich die Implementierung des mehrspaltigen Index wahrscheinlich nicht gelohnt.

In meiner Erfahrung mit beiden GDB-Typen habe ich festgestellt, dass die persönliche GDB etwa 50% größer als die Datei ist. Basierend auf den Daten, die Sie in Bezug auf Ihre Datei-GDB angegeben haben, würden Sie bei einer Konvertierung in eine PGDB wahrscheinlich eine persönliche GDB von ~ 300 MB erhalten. Wie ich gesehen habe, tritt bei der Arbeit mit MS Access-Datenbanken sowohl innerhalb von ESRI-Produkten als auch separat eine Leistungsverschlechterung auf, sobald die ".mdb" -Dateien erheblich größer als 100 MB werden.

Das andere Problem wäre wahrscheinlich, dass selbst wenn Sie Ihre Attributsuche beschleunigen könnten, Sie einen großen Leistungseinbruch sehen würden, wenn Sie sich im Datenrahmen bewegen und die Ansicht aktualisieren. Die Ebene würde einfach nicht so schnell zeichnen, wenn sie in einer PGDB wäre. Dieser Artikel zum Vergleich der Arten von Geodatabases enthält weitere Informationen zu den Leistungsunterschieden.

Wie bei vielen Dingen läuft die beste Wahl letztendlich auf Ihren Anwendungsfall hinaus. Wenn Sie viele datenbankspezifische Vorgänge ausführen möchten, z. B. Abfragen und Aktualisierungen, die Sie in der Access-Oberfläche ausführen können, ist die persönliche GDB möglicherweise besser. Wenn Sie nur Abfragen durchführen möchten, aber hauptsächlich die räumlichen Daten visualisieren möchten, fällt die Leistung definitiv auf die Seite der Datei-GDB.

Es gibt mindestens 9 Hauptgründe für die Verwendung von File Geodatabase gegenüber Personal Geodatabase. Leider gibt es noch viel mehr Gründe, die alte PGDB beizubehalten. Ihr Dilemma ist einer von ihnen. (keine ESRI-Veröffentlichung zu diesem Thema)

Ich glaube, der Hauptzweck von FGDB gegenüber PGDB ist die Speicherkapazität und Leistung von Geodaten (Zeichengeschwindigkeit, Abruf, räumliche Indizierung, räumliche Abfrage usw.) und nicht Funktionen wie mehrspaltige "Attribut" -Indizes und andere erweiterte SQL-Funktionen sind normalerweise ein wesentlicher Bestandteil eines DBMS. (Welche MS Access-basierte PGDB ist und welche nicht die ESRI-native FGDB) Als Randnotiz; Die maximale Dateigrößenbeschränkung einer MS Access-Datenbank beträgt 2 GB. Dies ist auch die maximale Größe einer einzelnen PGDB. Im Gegensatz dazu beträgt die FGDB-Dateigrößenbeschränkung 1 TB bis 256 TB.

ESRI gibt außerdem Folgendes an: Die Syntax, mit der Sie einen SQL-Ausdruck erstellen, hängt von der Datenquelle ab. Dies liegt daran, dass SQL zwar ein Standard ist, jedoch nicht alle Datenbanksoftware denselben SQL-Dialekt implementiert. und Um dateibasierte Daten abzufragen, einschließlich Datei-Geodatabases, Coverages, Shapefiles, INFO-Tabellen, dBASE-Tabellen, CAD- und VPF-Daten, verwenden Sie einen in ArcGIS implementierten SQL-Dialekt, der eine Teilmenge der in Personal und verfügbaren Funktionen unterstützt ArcSDE-Geodatabases.

Mit anderen Worten (und die PGDB- und ArcSDE-GDB ist ein Beweis dafür), wenn die dem DBMS zugrunde liegende Geodatabase diese Funktionalität unterstützt, sollte sie verfügbar sein . Aus diesem Grund können Sie wahrscheinlich einen mehrspaltigen Index in einer PGDB erstellen, der eine MS Access-Datenbank zugrunde liegt. Gleiches gilt für jede ArcSDE-Geodatabase mit einem zugrunde liegenden DBMS, das diese Funktionalität unterstützt.

Wie für File Geodabase ; In der FGDB-Version 9.2 unterstellte ESRI, dass einige dieser Merkmale und Funktionen in zukünftigen FGDB-Versionen hinzugefügt werden könnten. "Datei-Geodatabases unterstützen nicht alle für persönliche Geodatabases verfügbaren Features und Funktionen. In ArcGIS 9.2 umfassen die am häufigsten verwendeten Funktionen, die von File-Geodatabases nicht unterstützt werden, DISTINCT, GROUP BY und ORDER BY sowie die festgelegten Funktionen AVG, COUNT, MIN, MAX und SUM werden außerhalb von Unterabfragen nicht unterstützt. Die Unterstützung einiger dieser Abfragen wird wahrscheinlich in zukünftigen Versionen hinzugefügt. "

Vier Jahre später, in Version 10, sind keine dieser Funktionen und Merkmale verfügbar. ( Liste der verfügbaren Funktionen )

Es scheint, dass FGDB in Arbeit ist und mehrspaltige Indizierungsfunktionen benötigt, ebenso wie alle erforderlichen SQL DBMS-Funktionen. Ich denke, wir werden bei PGDB bleiben, bis ESRI-Entwickler entscheiden, dass es wichtig ist, seine Funktionalität auf die FGDB auszudehnen.

Als ich diesen Thread / dieses Problem wiederbelebte, fand ich, dass es nützlich sein kann, FGDB und PGDB nach Möglichkeit zu kombinieren. Wenn Sie beispielsweise eine Scratch-Geodatabase zu einer PGDB machen, wird die Leistung von Abfragen erheblich verbessert. Die Größe der PGDB sollte, wie oben erwähnt, nicht zu stark zunehmen.