¿Cuánta hinchazón de la base de datos es razonable?

Question

Utilizo geodatabases personales para almacenar todos los datos de mis proyectos (probablemente unas 10-20 clases de características en 2-4 conjuntos de datos de media). Utilizo la gdb personal porque me gusta poder conectarme a ella a través de otros productos de MS Office y utilizar mail-merge para informes y access para tablas dinámicas, etc, etc. Además, ArcGIS 10.1, Windows 7, datos ubicados en una unidad de red.

En los últimos meses he estado automatizando todas mis tareas aburridas usando arcpy y estoy notando una hinchazón sustancial en mis bases de datos después de ejecutar ciertas herramientas (de una caja de herramientas de python, no herramientas de stock de esri). Por ejemplo, esta mañana he ejecutado el script que itera a través de cada polígono en una clase de característica, selecciona todas las características que están dentro de ellos, suma sus campos [COUNT] y luego utiliza la herramienta CalculateField_management para escribir esa suma a un campo en la tabla de atributos de polígono. Hay aproximadamente 2.500 registros en el campo de polígonos, por lo que se realizan unas 2.500 iteraciones, seleccionando 1-5 registros de 6-7 clases de características durante cada iteración. Cuando la operación se completó, mi gdb se había hinchado hasta 2,0 GB (sí, el número mágico "ahora nada funcionará"). Después de ejecutar un simple 'Compress Database' en arcCatalog el tamaño se redujo a 32MB. Eso es una disminución del 98,5 por ciento, que parece atrozmente enorme.

Así que mi pregunta es: ¿Es una cantidad normal de contracción/incremento para una geodatabase personal o estoy haciendo algo mal? Además, si estoy haciendo algo mal, ¿qué estrategias puedo emplear para solucionarlo? ¿Habría ventajas significativas de rendimiento si utilizara una geodatabase de archivos en lugar de una personal?

Por último, cada vez soy más consciente de que la mayor parte de lo que estoy haciendo en arcpy podría lograrse más fácilmente utilizando SQL en un entorno de base de datos más robusto... ¿Es hora de dar el paso y empezar a aprender sobre PostgreSQL?

Answer 1

Parece que hay algunas cosas que pueden hacer que una base de datos Access crezca excesivamente.

1. El bloqueo de filas se trata en esta pregunta de Stackexchange: La base de datos MS-Access se hace muy grande durante las inserciones
   Parece que la solución sugerida es desactivar Row-Locking en la base de datos. Esto es algo que se desactiva en la propia base de datos Access, no a través de ArcGIS. Dicho esto, no estoy seguro de qué efectos, positivos o negativos, esto puede tener en relación con la interacción de ESRI. Una búsqueda rápida no apareció nada, por lo que no podría hacer daño a probarlo.

2. Este artículo técnico de Microsoft trata de Cómo prevenir el Bloat después de usar Data Access Objects(DAO). No estoy seguro del tipo de interfaz que utiliza ESRI para enlazar con la consulta de la base de datos Access y otras operaciones, pero imagino que también estarán relacionadas con esto.

Creo que estos abordan bastante bien el problema del tamaño. En el tiempo que llevo usando PGDB y bases de datos Access en general, he visto mucha fluctuación de tamaño. También ha habido algo que creció mucho mientras que los datos que contenían no parecían soportarlo. No parece que haya mucho que puedas hacer aparte de lo que estos artículos pueden ayudar.

Ahora, en la parte de su pregunta que tiene muchas más posibilidades, y preguntas.

En realidad, está haciendo dos preguntas diferentes.

1. ¿Debería aprender más SQL?
2. ¿Debería aprender a utilizar un RDBMS basado en servidor como PostgreSQL?

Pregunta nº 1 - Yo diría definitivamente que sí. Esto se aplicaría independientemente de cómo enfoques la pregunta número 2. Incluso si sigues usando Python y un GDB Personal, podrías empezar a mover algunas de tus operaciones de código Python a consultas SQL y pasarlas. Puedes hacer esto usando Arcpy como lo haces ahora, o en combinación con un módulo como pyodbc que le permite interactuar con cualquier número de formatos de bases de datos. Como dices en tu pregunta, aprender SQL te da la capacidad de realizar operaciones de forma mucho más eficiente.

Pregunta nº 2 - Esto, obviamente, también va a salir del lado del "Sí". Es más fácil dar ejemplos concretos de por qué aprender un RDBMS te beneficiará.
He aquí algunas:

1. El proceso de instalación y configuración de un verdadero RDBMS como PostgreSQL le obliga a familiarizarse con sus datos y cómo están estructurados. Hay tantos más controles potenciales sobre quién tiene acceso, y sobre lo que está permitido, que usted necesita poner un poco de pensamiento en sus datos cuando se configura por primera vez, ya que puede ser mucho más difícil de cambiar más tarde.
2. El hecho de que un RDBMS sea ÁCIDO -es una red de seguridad enorme y yo diría que relativamente oculta, al menos para el usuario profano. Con Access, si una consulta sale mal, puede corromper toda la tabla y, posiblemente, toda la base de datos. Saber que cuando se ejecuta una consulta, si sale mal, no afectará a la integridad de los datos que ya están allí, da mucha más flexibilidad.
3. Soporte multiusuario. Incluso si no se utiliza SDE o alguna otra capa de abstracción entre la base de datos y el SIG, se trata de un salto enorme. Un ejemplo personal se refiere a la construcción de tablas extendidas de atributos en una base de datos PostgreSQL. Cuando tenía las tablas en MS Access, si alguien hacía referencia a ellas en un .mxd No siempre podría editarlos o cambiar su estructura hasta que todos los demás bloqueos de usuario estuvieran liberados. Con PostgreSQL, puedo ver los datos en ArcGIS al mismo tiempo que actualizo los atributos y modifico la estructura de la tabla a través de la base de datos. Esto me ahorra mucho tiempo. También significa que una vez que tenga otros usuarios accediendo a estos mismos datos, podré hacer otros cambios durante el día sin tener que asegurarme de que todo el mundo ha cerrado sus referencias a la base de datos.
4. Alejarse de una estructura de datos en silos. Una vez que se centralizan los datos y todo el mundo puede acceder a ellos, se reduce la necesidad de que grupos más pequeños tengan sus propias copias de los mismos datos, o la única copia de algunos datos que no están dispuestos a compartir por temor a que se corrompan, etc. Si sabes cómo utilizar un RDBMS, puedes asegurarte de que todos los datos tienen una copia de seguridad adecuada, al tiempo que permites diferentes niveles de acceso a los distintos usuarios en función de sus necesidades individuales y organizativas. Además, utilizar una base de datos de este tipo reduce la probabilidad de que se produzca una situación en la que no puedas extraer datos para compartirlos con terceros. Esta historia es un buen ejemplo . Tenga en cuenta que el mayor problema en esta situación fue más la incapacidad de utilizar el software para extraer los datos a un formato utilizable que un problema con el almacenamiento de datos en sí. No obstante, pone de manifiesto el problema de silos de datos .

Mi último comentario se aplica a ambas preguntas, de por qué querrías aprender SQL o PostgreSQL. El hecho es que cada uno de ellos se convierte en una herramienta más que te ayuda en tu trabajo. Saber SQL te permite acceder a datos de diversas fuentes y realizar muchas operaciones con ellos sin necesidad de software especializado. Conocer PostgreSQL te introduce en una estructura de base de datos mucho más robusta. Tanto si acabas usándola como si usas una plataforma RDBMS diferente, verás que hay muchas similitudes, por lo que estarás adquiriendo conocimientos sobre múltiples sistemas. Python, SQL, PostgreSQL y MS Access son todos apropiados en circunstancias particulares, con cierto solapamiento. Estar familiarizado con todos ellos te permitirá aprovechar sus ventajas individuales para agilizar tu flujo de trabajo.