I geodatabase personali sono più adatti per la query rapida di attributi indicizzati rispetto ai geodatabase di file?

Sto preparando i dati per un'applicazione ArcGIS Engine che richiede i dati per cercare un indirizzo. A volte cerchiamo solo nel campo del nome della strada, solo nel campo del numero civico o entrambi. Quando si utilizzano geodatabase personali o geodatabase SDE, è possibile aggiungere un indice di attributo a più colonne oltre agli indici a colonna singola. Per qualche motivo, secondo l' articolo ESRI sulla creazione di indici di attributo, gli indici di attributo a più colonne non sono possibili quando si utilizzano database di file. Non menzionano il motivo per cui questo è il caso - forse i file geodatabase non ne hanno bisogno per qualche motivo?

Un indice multi-colonna sul campo del numero civico e sul campo del nome della via dovrebbe teoricamente migliorare le prestazioni della mia query quando si cercano entrambi i campi contemporaneamente, ma vale la pena passare all'utilizzo di un geodatabase personale? Ho la sensazione che gli svantaggi dell'utilizzo di un geodatabase personale possano negare i vantaggi dell'indice multi-colonna.

Ho avuto l'impressione che Esri voglia che ci allontaniamo dai database geografici personali, ma è questo un caso in cui i database geografici personali sono l'opzione migliore? Se hai qualche esperienza con questo, mi piacerebbe saperlo.

Per rispondere alla prima parte della tua domanda, penso che sia utile esaminare il testo aggiuntivo nel file della guida per la creazione di indici di attributi sugli indici a più colonne.

L'ordine in cui i campi compaiono in un indice a più colonne è importante. In un indice a più colonne con la colonna A che precede la colonna B, la colonna A verrà utilizzata per condurre la ricerca iniziale. Inoltre, un tale indice sarà molto più utile per le query che coinvolgono solo la colonna A di quanto non lo sarà per le query che coinvolgono solo la colonna B.
Crea un indice a più colonne su A e B. Questo indice sarebbe generalmente più efficiente per le query che coinvolgono entrambe le colonne. Per le query che coinvolgono solo A, questo indice sarebbe più lento di un indice solo su A. Questo indice sarebbe di scarsa utilità per le query che coinvolgono solo B. Per compensare, è possibile creare un indice aggiuntivo su B.

Entrambi questi passaggi mostrano che gli indici multi-colonna sono migliori per un uso specializzato. Inoltre, l'utilizzo di un tale indice per ordinare solo su una delle colonne incluse, potrebbe effettivamente compromettere le prestazioni. Per questo motivo, è probabile che saranno necessari singoli indici di colonna per ciascuno degli attributi inclusi in un indice multi-colonna.

Ho trovato un collegamento a un vecchio, ma interessante documento dell'ESRI che indica i 9 motivi per scegliere un file su un GDB personale . È interessante in quanto definisce specificamente le prestazioni come uno dei motivi. Parte di questo aumento delle prestazioni è dovuto al sistema di archiviazione basato su file. Penso che ciò potrebbe anche influire sulla mancanza di supporto multi-colonna. A differenza del GDB personale, che è un singolo file, un indice in un GDB file viene archiviato come file separato nella struttura GDB. Ciò significa che il file di indice e il file di attributo per una determinata featureclass dovranno essere collegati e accessibili insieme. Ho potuto vedere dove un indice multi-colonna avrebbe portato a saltare avanti e indietro tra i file di indice e attributo e potenzialmente causando un hit delle prestazioni che supera il guadagno delle prestazioni dell'indicizzazione.

Poiché ci sono già significativi miglioramenti delle prestazioni con il File GDB rispetto al GDB personale, probabilmente non valeva la pena implementare l'indice multi-colonna.

Nella mia esperienza di lavoro con entrambi i tipi di GDB, ho visto Personal GDB in esecuzione di circa il 50% più grande del file. Sulla base dei dati forniti in merito al file GDB, se si dovesse convertire in un PGDB, si otterrebbe probabilmente un GDB personale di ~ 300 MB. Da quello che ho visto, lavorando con i database MS Access, sia all'interno dei prodotti ESRI, sia separatamente, è che inizi a vedere il degrado delle prestazioni una volta che i file ".mdb" aumentano in modo significativo oltre le dimensioni di 100 MB.

L'altro problema sarebbe probabilmente che anche se si potesse accelerare la ricerca degli attributi, si vedrebbe un notevole successo di prestazioni legato allo spostamento nel frame di dati e all'aggiornamento della vista. Il layer semplicemente non disegnerebbe così velocemente se fosse in un PGDB. Questo articolo che confronta i tipi di database geografici fornisce ulteriori informazioni sulle differenze di prestazioni.

Come per molte altre cose, la scelta migliore alla fine si riduce a qual è il tuo caso d'uso. Se ci sono molte operazioni specifiche del database che vorresti eseguire, come query e aggiornamenti, che puoi fare nell'interfaccia di Access, allora il GDB personale potrebbe essere migliore. Se prevedi solo di eseguire alcune query, ma visualizzerai principalmente i dati spaziali, le prestazioni ricadono sicuramente sul lato del File GDB.

Esistono almeno 9 motivi principali per utilizzare File Geodatabase su Personal Geodatabase. Sfortunatamente, ci sono ancora molte altre ragioni per mantenere in giro il vecchio PGDB; il tuo dilemma è uno di questi. (nessuna pubblicazione ESRI su questo argomento)

Credo che lo scopo principale di FGDB su PGDB sia la capacità di archiviazione e le prestazioni dei dati spaziali (velocità di disegno, recupero, indicizzazione spaziale, query spaziale, ecc.) Piuttosto che funzionalità come gli indici di "attributo" a più colonne e altre funzioni SQL avanzate che sono normalmente parte integrante di qualsiasi DBMS. (Quale PGDB basato su MS Access è e l'FGDB nativo ESRI non lo è) Come nota a margine; Il limite massimo di dimensione del file di un database MS Access è di 2 GB, che è anche la dimensione massima di ogni singolo PGDB. Al contrario, il limite della dimensione del file FGDB è 1 TB spendibile a 256 TB.

ESRI afferma inoltre che: La sintassi utilizzata per creare un'espressione SQL varia in base all'origine dati. Questo perché, sebbene SQL sia uno standard, non tutti i software di database implementano lo stesso dialetto di SQL. e Per eseguire query su dati basati su file, inclusi geodatabase di file, coperture, shapefile, tabelle INFO, tabelle dBASE, dati CAD e VPF, si utilizza un dialetto di SQL implementato in ArcGIS che supporta un sottoinsieme delle caratteristiche e delle funzioni disponibili in personale e Database geografici ArcSDE.

In altre parole (e PGDB e ArcSDE GDB ne sono una prova) se il geodatabase sottostante DBMS supporta questa funzionalità, dovrebbe essere disponibile . Questo è probabilmente il motivo per cui sei in grado di creare un indice multi-colonna in un PGDB che ha un database MS Access sottostante. Lo stesso con qualsiasi geodatabase ArcSDE con un DBMS sottostante che supporta questa funzionalità.

Per quanto riguarda File Geodabase ; alla versione 9.2 FGDB ESRI ha insinuato che alcune di queste caratteristiche e funzioni potrebbero essere aggiunte nelle versioni future di FGDB, citando; "I geodatabase di file non supportano tutte le caratteristiche e le funzioni disponibili per i geodatabase personali. In ArcGIS 9.2, le funzioni più comunemente utilizzate non supportate dai geodatabase di file includono DISTINCT, GROUP BY e ORDER BY e le funzioni impostate AVG, COUNT, MIN, MAX e SUM non sono supportati al di fuori delle subquery. È probabile che il supporto per alcuni di questi venga aggiunto nelle versioni future. "

Quattro anni dopo alla versione 10 nessuna di queste funzioni e caratteristiche è disponibile. ( Elenco delle funzioni disponibili )

Sembra che FGDB sia un work in progress e ha bisogno di capacità di indicizzazione multi-colonna tanto quanto ha bisogno di tutte le funzioni SQL DBMS necessarie. Immagino che rimarremo bloccati con PGDB fino a quando gli sviluppatori ESRI non decideranno che è importante estenderne le funzionalità all'FGDB.

Rianimando questo thread / problema, ho scoperto che può essere utile combinare, ove possibile, FGDB e PGDB. Ad esempio, fare di un geodatabase scratch un PGDB ha notevolmente aiutato le prestazioni delle query. Le dimensioni del PGDB non dovrebbero aumentare troppo, come menzionato sopra.