Les géodatabases personnelles sont-elles mieux adaptées pour interroger rapidement les attributs indexés que les géodatabases fichier?

Je prépare des données pour une application ArcGIS Engine qui interroge les données pour rechercher une adresse. Parfois, nous recherchons uniquement le champ du nom de la rue, uniquement le champ du numéro de la maison, ou les deux. Lors de l'utilisation de géodatabases personnelles ou de géodatabases SDE, on peut ajouter un index d'attribut à plusieurs colonnes en plus des index à une seule colonne. Pour une raison quelconque, selon l' article ESRI Création d'index d'attributs, les index d'attributs à plusieurs colonnes ne sont pas possibles lors de l'utilisation de géodatabases fichier. Ils ne mentionnent pas pourquoi c'est le cas - peut-être que les géodatabases fichier n'en ont pas besoin pour une raison quelconque?

Un index multi-colonnes sur le champ du numéro de rue et le champ du nom de la rue devrait théoriquement améliorer les performances de ma requête lors de la recherche des deux champs à la fois, mais cela vaut-il la peine de passer à l'utilisation d'une géodatabase personnelle? J'ai le sentiment que les inconvénients de l'utilisation d'une géodatabase personnelle pourraient annuler les avantages de l'index multi-colonnes.

J'ai l'impression qu'Esri veut que nous nous éloignions des géodatabases personnelles, mais s'agit-il d'un cas où les géodatabases personnelles sont la meilleure option? Si vous avez une expérience avec cela, j'aimerais savoir.

Pour répondre à la première partie de votre question, je pense qu'il est utile de consulter le texte supplémentaire du fichier d'aide Création d'index d'attributs sur les index multi-colonnes.

L'ordre dans lequel les champs apparaissent dans un index multicolonne est important. Dans un index multicolonne avec la colonne A précédant la colonne B, la colonne A sera utilisée pour effectuer la recherche initiale. En outre, un tel index sera beaucoup plus utile pour les requêtes impliquant uniquement la colonne A que pour les requêtes impliquant la colonne B uniquement.
Créez un index multicolonne sur A et B. Cet index serait généralement plus efficace pour les requêtes impliquant les deux colonnes. Pour les requêtes impliquant uniquement A, cet index serait plus lent qu'un index sur A seul. Cet index serait peu utile pour les requêtes impliquant uniquement B. Pour compenser, vous pourriez créer un index supplémentaire sur B.

Ces deux passages montrent que les index multi-colonnes sont meilleurs pour une utilisation spécialisée. De plus, l'utilisation d'un tel index pour trier sur une seule des colonnes incluses peut en fait nuire aux performances. Pour cette raison, il est probable que des index de colonnes individuels seront nécessaires pour chacun des attributs inclus dans un index multi-colonnes.

J'ai trouvé un lien vers un document ancien mais intéressant par ESRI indiquant les 9 raisons de choisir un fichier plutôt qu'un GDB personnel . Il est intéressant en ce qu'il appelle spécifiquement la performance comme étant une des raisons. Une partie de ce gain de performances est due au système de stockage basé sur les fichiers. Je pense que cela pourrait également jouer sur le manque de support multi-colonnes. Contrairement à Personal GDB, qui est un fichier unique, un index dans un fichier GDB est stocké en tant que fichier distinct dans la structure GDB. Cela signifie que le fichier d'index et le fichier d'attributs pour une classe de caractéristiques particulière devront être liés et accessibles ensemble. Je pouvais voir où un index multi-colonnes conduirait à des allers-retours entre les fichiers d'index et d'attributs, et potentiellement à un impact sur les performances qui l'emporte sur le gain de performances d'indexation.

Puisqu'il y a déjà des gains de performances importants avec le GDB de fichier par rapport au GDB personnel, cela ne valait probablement pas la peine d'implémenter l'index multi-colonnes.

Dans mon expérience de travail avec les deux types de GDB, j'ai vu le Personal GDB s'exécuter environ 50% plus grand que le fichier. Sur la base des données que vous avez fournies concernant votre GDB de fichier, si vous deviez convertir en PGDB, vous vous retrouveriez probablement avec un GDB personnel de ~ 300 Mo. D'après ce que j'ai vu, travailler avec les bases de données MS Access, à la fois dans les produits ESRI et séparément, c'est que vous commencez à voir une dégradation des performances une fois que les fichiers ".mdb" ont augmenté de manière significative au-dessus de 100 Mo.

L'autre problème serait probablement que même si vous pouviez accélérer vos recherches d'attributs, vous verriez un impact important sur les performances lié au déplacement dans le bloc de données et à l'actualisation de la vue. La couche ne dessinerait tout simplement pas aussi vite si elle se trouvait dans une PGDB. Cet article comparant les types de géodatabases donne plus d'informations sur les différences de performances.

Comme pour beaucoup de choses, le meilleur choix se résumera finalement à votre cas d'utilisation. S'il y a beaucoup d'opérations spécifiques à la base de données que vous souhaitez effectuer, comme des requêtes et des mises à jour, que vous pouvez effectuer dans l'interface Access, alors la Personal GDB peut être meilleure. Si vous envisagez uniquement de faire des requêtes, mais que vous visualiserez principalement les données spatiales, les performances se situeront certainement du côté du fichier GDB.

Il existe au moins 9 principales raisons d'utiliser la géodatabase fichier sur la géodatabase personnelle. Malheureusement, il y a encore beaucoup plus de raisons de conserver l'ancien PGDB; votre dilemme en fait partie. (pas de publication ESRI sur ce sujet)

Je crois que l'objectif principal de FGDB sur PGDB est la capacité de stockage et les performances des données spatiales (vitesse de dessin, récupération, indexation spatiale, interrogation spatiale, etc.) plutôt que des fonctionnalités telles que les index "d'attributs" multi-colonnes et d'autres fonctions SQL avancées qui font normalement partie intégrante de tout SGBD. (Quelle est la PGDB basée sur MS Access et la FGDB native ESRI ne l'est pas) La taille maximale de fichier d'une base de données MS Access est de 2 Go, ce qui correspond également à la taille maximale de n'importe quelle PGDB. En revanche, la limite de taille de fichier FGDB est de 1 To extensible à 256 To.

ESRI indique également que: La syntaxe que vous utilisez pour créer une expression SQL diffère selon la source de données. En effet, bien que SQL soit une norme, tous les logiciels de base de données n'implémentent pas le même dialecte SQL. et Pour interroger des données basées sur des fichiers, y compris des géodatabases fichier, des couvertures, des fichiers de formes, des tables INFO, des tables dBASE, des données CAD et VPF, vous utilisez un dialecte SQL implémenté dans ArcGIS qui prend en charge un sous-ensemble des fonctionnalités et fonctions disponibles dans les versions personnelles et Géodatabases ArcSDE.

En d'autres termes (et le PGDB et le GDB ArcSDE en sont la preuve) si la géodatabase sous-jacente au SGBD prend en charge cette fonctionnalité, elle doit être disponible . C'est probablement pourquoi vous pouvez créer un index multi-colonnes dans une PGDB qui a une base de données MS Access sous-jacente. Même chose avec toute géodatabase ArcSDE avec un SGBD sous-jacent qui prend en charge cette fonctionnalité.

Comme pour la géodabase fichier ; dans la version 9.2 de FGDB, ESRI a insinué que certaines de ces caractéristiques et fonctions pourraient être ajoutées dans les futures versions de FGDB, citant; "Les géodatabases fichier ne prennent pas en charge toutes les fonctionnalités et fonctions disponibles pour les géodatabases personnelles. Dans ArcGIS 9.2, les fonctions les plus couramment utilisées non prises en charge par les géodatabases fichier sont DISTINCT, GROUP BY et ORDER BY, et les fonctions définies AVG, COUNT, MIN, MAX et SUM ne sont pas pris en charge en dehors des sous-requêtes. La prise en charge de certaines d'entre elles sera probablement ajoutée dans les versions futures. "

Quatre ans plus tard, dans la version 10, aucune de ces fonctions et fonctionnalités n'est disponible. ( Liste des fonctions disponibles )

Il semble que FGDB soit un travail en cours et qu'il a besoin de capacités d'indexation multi-colonnes autant qu'il a besoin de toutes les fonctions SQL DBMS nécessaires. Je suppose que nous serons bloqués avec PGDB jusqu'à ce que les développeurs ESRI décident qu'il est important d'étendre ses fonctionnalités au FGDB.

En faisant revivre ce fil / problème, j'ai trouvé qu'il peut être utile de combiner, si possible, FGDB et PGDB. Par exemple, faire d'une scratch-géodatabase une PGDB a grandement aidé les performances des requêtes. La taille de la PGDB ne doit pas trop augmenter, comme mentionné ci-dessus.