Rendimiento a un Precio: File Geodatabases y Soporte SQL

JoshuaBixby

<\/HEAD>

Entre comenzar un nuevo puesto y disfrutar del verano, ha pasado un tiempo desde la última vez que escribí en el blog.  Aunque planeo terminar la serie Iterable Cursor, me encontré de frente con una limitación, y un error subsecuente, de la file geodatabase que pensé que valía la pena compartir.  Primero, la limitación....<\/EM><\/P><\/P>Cuando se introdujo la file geodatabase (FGDB) en 2006, se promocionó como una alternativa mejorada y de alto rendimiento a la personal geodatabase (PGDB).  Es cierto que los grandes conjuntos de datos y grandes colecciones de conjuntos de datos representan desafíos para la personal geodatabase.  Por un lado, los archivos de datos de Microsoft Access (*.mdb;*.accdb) están limitados a 2 GB de tamaño, lo cual no era mucho en 2006 pero hoy es prácticamente nada.  Además del límite de tamaño de archivo, el rendimiento de la personal geodatabase comienza a degradarse alrededor de 500 MB de datos totales (ver Tipos de geodatabases<\/A>).  Otro factor probable, pero que Esri no aborda, es la descontinuación del motor de base de datos Jet a mediados de los años 2000.<\/P>

<\/P>

Dando un paseo por el camino de los recuerdos, o los Esri Blogs como sea, se encuentra

Cinco razones por las que deberías usar la File Geodatabase<\/A>:<\/P>

Tamaño<\/STRONG><\/P>El tamaño de la base de datos está limitado solo por el espacio disponible en disco. Por defecto, las tablas individuales y las clases de entidad pueden tener hasta 1 TB. Con el uso de palabras clave de configuración esto puede ampliarse hasta 256 TB.<\/P><\/P>Versatilidad<\/STRONG><\/P>Funciona en muchos sistemas operativos diferentes incluyendo Windows y UNIX (Solaris y Linux)<\/P><\/P>Velocidad<\/STRONG><\/P>Proporciona un excelente rendimiento y escalabilidad. Por ejemplo, para soportar conjuntos individuales que contienen más de 300 millones de entidades y conjuntos que pueden escalar más allá de 500 GB por archivo con un rendimiento muy rápido....<\/P><\/P>Modelo de Edición<\/STRONG><\/P>La File Geodatabase usa un modelo de edición similar a shapefiles, soportando un editor y múltiples lectores.  Cada clase de entidad independiente, tabla y conjunto de entidades puede ser editado por diferentes editores simultáneamente pero solo puede tener un editor realizando ediciones en ellos en cualquier momento dado....<\/P><\/P>Compresión<\/STRONG><\/P>Las File Geodatabases también permiten a los usuarios comprimir clases de entidad y tablas a un formato solo lectura para reducir aún más los requisitos de almacenamiento. Esto reduce la huella total en disco de la Geodatabase sin reducir el rendimiento.<\/P><\/BLOCKQUOTE><\/P>No puedo discutir ninguna de las cinco razones promovidas en el post del blog, creo que cada una es precisa y una buena razón para que Esri trabajara en crear un nuevo formato basado en sistema de archivos para geodatabases.  Pero como algunos comentarios del blog hace ocho años señalan, la file geodatabase no era perfecta entonces y todavía tiene sus fallas hoy. <\/P><\/P>Para algunos, la mayor falla de la file geodatabase es su carácter propietario.  Esto no es realmente un cambio respecto a las personal geodatabases, ya que Access\Jet también es propietario, pero representa una oportunidad perdida.  Después de varios años Esri finalmente lanzó la API file geodatabase (<\/EM><A href="https:\/\/blogs.esri.com\/esri\/arcgis\/2010\/12\/13\/file-geodatabase-api-details\/\

bharold

Joshua, are there workflows you have migrated to GeoPackage to take advantage of its SQL support in any 3rd party software or Data Interoperability/FME?