Estoy preparando datos para una aplicación ArcGIS Engine que consulta los datos para buscar una dirección. A veces buscamos solo en el campo del nombre de la calle, solo en el campo del número de casa, o en ambos. Cuando se utilizan geodatabases personales o geodatabases SDE, se puede agregar un índice de atributo de varias columnas además de los índices de una sola columna. Por alguna razón, de acuerdo con el artículo Creación de índices de atributos de ESRI, los índices de atributos de varias columnas no son posibles cuando se utilizan geodatabases de archivos. No mencionan por qué este es el caso, ¿tal vez las geodatabases de archivos no las necesitan por alguna razón?
Un índice de varias columnas en el campo del número de casa y el campo del nombre de la calle debería mejorar teóricamente el rendimiento de mi consulta al buscar en ambos campos a la vez, pero ¿vale la pena cambiar a usar una geodatabase personal? Tengo la sensación de que las desventajas de usar una geodatabase personal podrían negar los beneficios del índice de varias columnas.
He tenido la impresión de que Esri quiere que nos alejemos de las geodatabases personales, pero ¿es este el caso donde las geodatabases personales son la mejor opción? Si tienes alguna experiencia con esto, me encantaría saberlo.
Respuestas:
Para responder a la primera parte de su pregunta, creo que es útil mirar el texto adicional en el archivo de ayuda Creación de índices de atributos sobre índices de columnas múltiples.
Ambos pasajes muestran que los índices de varias columnas son mejores para uso especializado. Además, el uso de dicho índice para ordenar solo una de las columnas incluidas, en realidad podría dañar el rendimiento. Por esta razón, es probable que los índices de columnas individuales sean necesarios para cada uno de los atributos incluidos en un índice de varias columnas.
Encontré un enlace a un documento antiguo pero interesante de ESRI que indica las 9 razones para elegir un archivo en lugar de un GDB personal . Es interesante porque específicamente llama al rendimiento como una de las razones. Parte de esta ganancia de rendimiento se debe al sistema de almacenamiento basado en archivos. Creo que esto también podría jugar con la falta de soporte de múltiples columnas. A diferencia del Personal GDB, que es un archivo único, un índice en un Archivo GDB se almacena como un archivo separado en la estructura GDB. Esto significa que el archivo de índice y el archivo de atributos para una clase de entidad en particular tendrán que vincularse y acceder juntos. Pude ver dónde un índice de varias columnas conduciría a saltar de un lado a otro entre los archivos de índice y atributo, y potencialmente causar un impacto en el rendimiento que supera la ganancia de rendimiento de indexación.
Dado que ya hay ganancias significativas de rendimiento con el File GDB sobre el Personal GDB, probablemente no valía la pena implementar el índice de varias columnas.
En mi experiencia trabajando con ambos tipos de GDB, he visto el Personal GDB ejecutándose aproximadamente un 50% más grande que el archivo. Según los datos que proporcionó con respecto a su archivo GDB, si fuera a convertir a un PGDB, probablemente terminaría con un ~ 300 MB de GDB personal. Por lo que he visto, trabajar con bases de datos de MS Access, tanto dentro de los productos ESRI como por separado, es que comienza a ver una degradación del rendimiento una vez que los archivos ".mdb" aumentan significativamente más de 100 MB de tamaño.
El otro problema probablemente sería que incluso si pudiera acelerar sus búsquedas de atributos, vería un gran impacto en el rendimiento relacionado con moverse en el marco de datos y actualizar la vista. La capa simplemente no se dibujaría tan rápido si estuviera en una PGDB. Este artículo que compara los tipos de geodatabases proporciona más información sobre las diferencias de rendimiento.
Al igual que con muchas cosas, la mejor opción finalmente se reducirá a cuál es su caso de uso. Si hay muchas operaciones específicas de la base de datos que le gustaría realizar, como consultas y actualizaciones, que puede hacer en la interfaz de Access, entonces el GDB personal puede ser mejor. Si solo planea hacer algunas consultas, pero principalmente visualizará los datos espaciales, entonces el rendimiento definitivamente recae en el lado del archivo GDB.
fuente
Hay al menos 9 razones principales para usar la Geodatabase de archivos sobre la Geodatabase personal. Desafortunadamente, todavía hay muchas más razones para mantener el viejo PGDB; tu dilema es uno de ellos. (no hay publicación de ESRI sobre este tema)
Creo que el objetivo principal de FGDB sobre PGDB es la capacidad de almacenamiento y el rendimiento de los datos espaciales (velocidad de dibujo, recuperación, indexación espacial, consulta espacial, etc.) en lugar de la funcionalidad, como los índices de "atributos" de varias columnas y otras funciones avanzadas de SQL que normalmente son una parte integral de cualquier DBMS. (Qué PGDB basado en MS Access es y el FGDB nativo de ESRI no lo es) Como nota al margen; El límite máximo de tamaño de archivo de una base de datos de MS Access es de 2 GB, que también es el tamaño máximo de cualquier PGDB. Por el contrario, el límite de tamaño de archivo FGDB es de 1 TB prescindible a 256 TB.
ESRI también afirma que: La sintaxis que usa para construir una expresión SQL difiere según la fuente de datos. Esto se debe a que aunque SQL es un estándar, no todo el software de base de datos implementa el mismo dialecto de SQL. y Para consultar datos basados en archivos, incluidas geodatabases de archivos, coberturas, archivos de forma, tablas INFO, tablas dBASE, CAD y datos VPF, utiliza un dialecto de SQL implementado en ArcGIS que admite un subconjunto de las características y funciones disponibles en personal y Geodatabases de ArcSDE.
En otras palabras (y el PGDB y ArcSDE GDB es una prueba de eso) si la geodatabase subyacente DBMS admite esta funcionalidad, entonces debería estar disponible . Esta es probablemente la razón por la que puede crear un índice de varias columnas en una PGDB que tiene una base de datos MS Access subyacente. Lo mismo con cualquier geodatabase de ArcSDE con un DBMS subyacente que admita esta funcionalidad.
En cuanto a la geodabase de archivos ; en la versión 9.2 FGDB, ESRI insinuó que algunas de estas características y funciones podrían agregarse en futuras versiones de FGDB, citando; "Las geodatabases de archivos no son compatibles con todas las características y funciones disponibles para las geodatabases personales. En ArcGIS 9.2, las funciones más utilizadas que no son compatibles con las geodatabases de archivos incluyen DISTINCT, GROUP BY y ORDER BY, y las funciones establecidas AVG, COUNT, MIN, MAX y SUM no se admiten fuera de las subconsultas. Es probable que se agregue compatibilidad con algunas de estas en futuras versiones ".
Cuatro años después, en la versión 10, ninguna de estas funciones y características está disponible. ( Lista de funciones disponibles )
Parece que FGDB es un trabajo en progreso y necesita capacidades de indexación de múltiples columnas tanto como necesita todas las funciones SQL DBMS necesarias. Supongo que nos quedaremos atrapados con PGDB hasta que los desarrolladores de ESRI decidan que es importante extender su funcionalidad al FGDB.
fuente
Al revivir este hilo / problema, descubrí que puede ser útil combinar, cuando sea posible, FGDB y PGDB. Por ejemplo, convertir una geodatabase reutilizable en una PGDB ayudó mucho al rendimiento de las consultas. El tamaño de la PGDB no debería aumentar demasiado, como se mencionó anteriormente.
fuente