Desempenho a um Preço: File Geodatabases e Suporte SQL

JoshuaBixby

<\/HEAD>

Entre começar uma nova posição e aproveitar o verão, faz um tempo desde a última vez que escrevi no blog.  Embora eu planeje terminar a série Iterable Cursor, esbarrei em uma limitação, e um bug subsequente, do file geodatabase que achei que valia a pena compartilhar.  Primeiro, a limitação....<\/EM><\/P><\/P>Quando o file geodatabase (FGDB) foi introduzido em 2006, foi anunciado como uma alternativa aprimorada e de alto desempenho ao personal geodatabase (PGDB).  É verdade que grandes conjuntos de dados e grandes coleções de conjuntos de dados apresentam desafios para o personal geodatabase.  Por um lado, os arquivos de dados do Microsoft Access (*.mdb;*.accdb) são limitados a 2 GB de tamanho, o que não era muito em 2006, mas é praticamente nada hoje.  Além do limite de tamanho do arquivo, o desempenho do personal geodatabase começa a degradar por volta de 500 MB de dados totais (veja Tipos de geodatabases<\/A>).  Outro fator provável, mas que a Esri não aborda, é a descontinuação do mecanismo de banco de dados Jet em meados dos anos 2000.<\/P>

<\/P>

Fazendo uma viagem pela memória, ou pelos Esri Blogs, pode-se encontrar

Cinco razões pelas quais você deveria estar usando o File Geodatabase<\/A>:<\/P>

Tamanho<\/STRONG><\/P>O tamanho do banco de dados é limitado apenas pelo espaço disponível no disco. Por padrão, tabelas individuais e classes de feição podem ter até 1 TB. Com o uso de palavras-chave de configuração isso pode ser expandido para 256 TB.<\/P><\/P>Versatilidade<\/STRONG><\/P>Funciona em muitos sistemas operacionais diferentes incluindo Windows e UNIX (Solaris e Linux)<\/P><\/P>Velocidade<\/STRONG><\/P>Oferece excelente desempenho e escalabilidade. Por exemplo, para suportar conjuntos de dados individuais contendo bem mais de 300 milhões de feições e conjuntos de dados que podem escalar além de 500 GB por arquivo com desempenho muito rápido....<\/P><\/P>Modelo de Edição<\/STRONG><\/P>O File Geodatabase usa um modelo de edição semelhante aos shapefiles, suportando um editor e múltiplos leitores.  Cada classe de feição independente, tabela e conjunto de feições pode ser editado por diferentes editores simultaneamente, mas só pode ter um editor realizando edições neles a qualquer momento....<\/P><\/P>Compressão<\/STRONG><\/P>File Geodatabases também permitem aos usuários comprimir classes de feição e tabelas para um formato somente leitura para reduzir ainda mais os requisitos de armazenamento. Isso reduz a pegada geral do Geodatabase no disco sem reduzir o desempenho.<\/P><\/BLOCKQUOTE><\/P>Não posso discordar de nenhuma das cinco razões defendidas no post do blog, acho que cada uma é precisa e uma boa razão para a Esri trabalhar na criação de um novo formato baseado em sistema de arquivos para geodatabase (na época).  Mas como alguns dos comentários com oito anos no blog apontam, o file geodatabase não era perfeito naquela época e ainda tem suas falhas hoje. <\/P><\/P>Para alguns, a maior falha do file geodatabase é a propriedade proprietária.  Isso não é realmente uma mudança em relação aos personal geodatabases, já que Access\Jet também é proprietário, mas representa uma oportunidade perdida.  Após vários anos a Esri finalmente lançou a API do 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?