Os bancos de dados geográficos pessoais são mais adequados para consultar rapidamente atributos indexados do que os bancos de dados geográficos de arquivos?

Estou preparando dados para um aplicativo ArcGIS Engine que consulta os dados para procurar um endereço. Às vezes, pesquisamos apenas no campo do nome da rua, apenas no campo do número da casa ou em ambos. Ao usar bancos de dados geográficos pessoais ou bancos de dados SDE, é possível adicionar um índice de atributo de várias colunas, além de índices de coluna única. Por alguma razão, de acordo com o artigo Criando Índices de Atributos ESRI, índices de atributos com várias colunas não são possíveis ao usar bancos de dados geográficos de arquivos. Eles não mencionam por que esse é o caso - talvez os bancos de dados geográficos de arquivos não precisem deles por algum motivo?

Um índice de várias colunas no campo de número da casa e no nome da rua deve teoricamente melhorar o desempenho da minha consulta ao pesquisar os dois campos de uma só vez, mas vale a pena mudar para o uso de um geodatabase pessoal? Sinto que as desvantagens do uso de um banco de dados geográfico pessoal podem negar os benefícios do índice de várias colunas.

Fiquei com a impressão de que a Esri quer que nos afastemos dos bancos de dados pessoais, mas será esse o caso em que os bancos de dados pessoais são a melhor opção? Se você tem alguma experiência com isso, eu adoraria saber.

Para responder à primeira parte da sua pergunta, acho que ajuda examinar o texto adicional no arquivo de ajuda Criando índices de atributos sobre índices de várias colunas.

A ordem na qual os campos aparecem em um índice de várias colunas é importante. Em um índice de várias colunas com a coluna A anterior à coluna B, a coluna A será usada para conduzir a pesquisa inicial. Além disso, esse índice será muito mais útil para consultas que envolvem apenas a coluna A do que para consultas que envolvam apenas a coluna B.
Crie um índice de várias colunas em A e B. Esse índice normalmente seria mais eficiente para consultas que envolvem as duas colunas. Para consultas que envolvem apenas A, esse índice seria mais lento que um índice somente em A. Esse índice seria pouco útil para consultas que envolvem apenas B. Para compensar, você pode criar um índice adicional em B.

Ambas as passagens mostram que os índices de várias colunas são melhores para uso especializado. Além disso, o uso desse índice para classificar apenas uma das colunas incluídas pode prejudicar o desempenho. Por esse motivo, é provável que índices de colunas individuais sejam necessários para cada um dos atributos incluídos em um índice de várias colunas.

Encontrei um link para um documento antigo, mas interessante, da ESRI, indicando as 9 razões para escolher um arquivo em vez de um GDB pessoal . É interessante, pois chama especificamente o desempenho como uma das razões. Parte desse ganho de desempenho se deve ao sistema de armazenamento baseado em arquivo. Eu acho que isso também pode estar relacionado à falta de suporte a várias colunas. Diferentemente do GDB Pessoal, que é um único arquivo, um índice em um GDB de Arquivo é armazenado como um arquivo separado na estrutura do GDB. Isso significa que o arquivo de índice e o arquivo de atributo para uma classe de característica específica precisarão ser vinculados e acessados ​​juntos. Pude ver onde um índice de várias colunas levaria a alternar entre os arquivos de índice e atributo, e potencialmente causando uma ocorrência de desempenho que supera o ganho de desempenho de indexação.

Como já existem ganhos de desempenho significativos com o File GDB sobre o Personal GDB, provavelmente não valeu a pena implementar o índice de várias colunas.

Na minha experiência trabalhando com os dois tipos de GDB, vi o GDB pessoal sendo executado cerca de 50% maior que o arquivo. Com base nos dados que você forneceu sobre o seu File GDB, se você converter para um PGDB, provavelmente terá um GDB pessoal de ~ 300 MB. Pelo que vi, trabalhar com bancos de dados do MS Access, tanto nos produtos ESRI quanto separadamente, é que você começa a ver a degradação do desempenho quando os arquivos ".mdb" aumentam significativamente mais de 100 MB.

O outro problema provavelmente seria que, mesmo que você pudesse acelerar suas pesquisas de atributo, veria um grande impacto no desempenho relacionado à movimentação no quadro de dados e à atualização da exibição. A camada simplesmente não seria tão rápida se estivesse em um PGDB. Este artigo comparando os tipos de bancos de dados geográficos fornece mais informações sobre as diferenças de desempenho.

Como em muitas coisas, a melhor opção se resume ao que é seu caso de uso. Se houver muitas operações específicas do banco de dados que você gostaria de executar, como consultas e atualizações, que você pode executar na interface do Access, o GDB pessoal poderá ser melhor. Se você planeja fazer algumas consultas, mas visualiza principalmente os dados espaciais, o desempenho definitivamente fica do lado do GDB de arquivo.

Há pelo menos 9 razões principais para usar o Geodatabase de Arquivo em vez do Geodatabase Pessoal. Infelizmente, ainda existem muitas outras razões para manter o antigo PGDB por perto; seu dilema é um deles. (nenhuma publicação da ESRI sobre este tópico)

Eu acredito que o objetivo principal do FGDB sobre o PGDB é a capacidade de armazenamento e o desempenho de dados espaciais (velocidade de desenho, recuperação, indexação espacial, consulta espacial etc.), em vez de funcionalidades como índices de "atributo" de várias colunas e outras funções SQL avançadas que normalmente são parte integrante de qualquer SGBD. (Qual PGDB baseado no MS Access e o FGDB nativo da ESRI não é) Como uma observação lateral; O limite máximo de tamanho de arquivo de um banco de dados do MS Access é de 2 GB, que também é o tamanho máximo de qualquer PGDB único. Por outro lado, o limite de tamanho do arquivo FGDB é de 1 TB, dispensável a 256 TB.

A ESRI também afirma que: A sintaxe usada para criar uma expressão SQL difere dependendo da fonte de dados. Isso ocorre porque, embora o SQL seja um padrão, nem todos os softwares de banco de dados implementam o mesmo dialeto do SQL. e dados baseados em arquivos consulta para, incluindo geodatabases de arquivos, coberturas, shapefiles, mesas Info, tabelas do dBASE, CAD e dados VPF, você usa um dialeto do SQL implementado dentro de ArcGIS que suporta um subconjunto dos recursos e funções disponíveis em pessoal e Bancos de dados geográficos ArcSDE.

Em outras palavras (e o PGDB e o ArcSDE GDB são uma prova disso) se o banco de dados geográfico subjacente ao DBMS suportar essa funcionalidade, ele deverá estar disponível . Provavelmente, você pode criar um índice de várias colunas em um PGDB que possui um banco de dados subjacente do MS Access. O mesmo acontece com qualquer geodatabase do ArcSDE com um DBMS subjacente que suporta essa funcionalidade.

Quanto ao File Geodabase ; na versão 9.2 do FGDB, a ESRI insinuou que alguns desses recursos e funções podem ser adicionados em versões futuras do FGDB, citando; "Os bancos de dados geográficos de arquivos não oferecem suporte a todos os recursos e funções disponíveis para bancos de dados pessoais. No ArcGIS 9.2, as funções mais usadas não suportadas pelos bancos de dados geográficos incluem DISTINCT, GROUP BY e ORDER BY, e as funções definidas AVG, COUNT, MIN, MAX e SUM não são suportados fora de subconsultas. É provável que o suporte para alguns deles seja adicionado em versões futuras. "

Quatro anos depois, na versão 10, nenhuma dessas funções e recursos estão disponíveis. ( Lista de funções disponíveis )

Parece que o FGDB é um trabalho em andamento e precisa de recursos de indexação de várias colunas tanto quanto de todas as funções necessárias do SQL DBMS. Acho que ficaremos presos ao PGDB até que os desenvolvedores da ESRI decidam que é importante estender sua funcionalidade ao FGDB.

Revivendo esse tópico / questão, descobri que pode ser útil combinar, sempre que possível, FGDB e PGDB. Por exemplo, tornar um PGDB de banco de dados de rascunho um PGDB ajudou muito o desempenho das consultas. O tamanho do PGDB não deve aumentar muito, como mencionado acima.