Qual é a diferença entre ArcSDE e bancos de dados habilitados espacialmente?

SDE [ArcSDE] pode se referir a pelo menos duas coisas: a organização de seus dados no banco de dados (o SDE Schema) ou um serviço que escuta conexões de clientes (o serviço SDE). Geralmente eles andam de mãos dadas – o serviço SDE é vinculado a um esquema SDE em um banco de dados.

Em seu estado “mais puro” (ou talvez mais sujo), SDE lida com todos os cálculos espaciais e apenas armazena dados em seu banco de dados como BLOBs e outros tipos de SQL nativos. Algumas funções de banco de dados, como indexação de texto ou XML, são usadas para melhorar o desempenho, mas geralmente o banco de dados não “sabe” que está servindo dados espaciais. Há apenas um monte de tabelas, visualizações e procedimentos, e eles estão cheios de dados e funções.

Com um banco de dados habilitado espacialmente, o banco de dados ESTÁ ciente de que os dados têm uma localização. Portanto, você pode colocar consultas de localização diretamente em suas instruções SQL. Talvez isso seja bom para você , realmente depende de quem está consumindo seus dados. Se seus consumidores de dados são fluentes em SQL, é ótimo! Se seus consumidores de dados são fluentes em ArcMap, eles provavelmente não se importariam.

Mais recentemente, fomos capazes de combinar os dois, usando SDE para traduzir para um tipo espacial nativo subjacente. Além disso, podemos usar “conexão direta” para ignorar o serviço SDE e apenas fazer com que o aplicativo do consumidor (ArcMap, servidor ArcGIS, etc) se conecte diretamente ao banco de dados. Pessoalmente, tive vários níveis de sucesso com conexões diretas.

Benefícios de usar ArcSDE:

• Integração perfeita com clientes ESRI
• Bom desempenho
• Algumas funcionalidades de banco de dados subjacentes podem ser expostas (visualizações espaciais, índices)

Desvantagens de usar SDE:

• Pode ser difícil recuperar de dados corrompidos
• A licença é vinculado ao banco de dados
• Acesso fácil à geometria sem o uso do software ESRI

Benefícios para um banco de dados espacialmente habilitado:

• Dados facilmente acessível a qualquer cliente SQL
• Os dados podem ser gerenciados usando ferramentas de banco de dados existentes (backup, restauração, análise)
• Formatos abertos disponíveis

Desvantagens para usando um banco de dados habilitado espacialmente:

• Clientes (software) podem não ser capazes de se conectar diretamente aos seus dados e podem ter que usar protocolos ou exportações ineficientes para vê-los
• As referências espaciais às vezes são difíceis de aplicar ou manter consistentes
• Pode incorrer em configuração extra ou sobrecarga de gerenciamento

Eu tenho m mais experiência com SDE simples, portanto, provavelmente há mais pontos para o banco de dados habilitado espacialmente.

Espero que isso ajude!

Comentários

• Você estaria infringindo o licenciamento da ESRI se acessasse os dados diretamente e não por meio do serviço SDE.
• Não há violação. A conexão direta ESRI não usa nenhum serviço SDE (pelo menos na extremidade do servidor). Além disso, eles publicaram muitos artigos sobre o uso de PostGres, MSSQL e WKT como o tipo de armazenamento espacial ao usar SDE, que permite a comunicação direta com os dados espaciais. E mais uma vez, tive que limpar o SDE, acessando os dados diretamente quando ele quebrou. Outro benefício dos bancos de dados habilitados espacialmente é que o banco de dados pode fazer o trabalho em vez de trazer todos os dados para um cliente e fazer com que ele faça o trabalho.
• @CrazyEnigma: citation needed.
• ótima descrição de SDE vs ST Geometry @mwalker Obrigado
• re: referências espaciais, acho que é o oposto. As referências espaciais em PostGIS são padrão e os SRIDs são os mesmos que os códigos EPSG para SRS aplicáveis. Com SDE, pelo menos a 9,3x, os SRIDS incorporam extensões, etc., portanto, você pode ter dois SRIDs diferentes para o mesmo Sistema de Referência Espacial. Isso causa problemas se você quiser usar SQL espacial.

Esta é minha resposta de uma linha: Use SDE quando precisar de acesso de vários usuários aos seus dados geoespaciais.

Digamos que você queira que vários usuários editem seus dados: use o SDE. Digamos que você queira veicular dados e permitir que sejam editados na web: use SDE. Se você for uma pequena loja, com um cara de GIS, não use SDE.

Se você é a única pessoa que usa seus dados espaciais, SDE não é para você. Se você não precisa de edição multiusuário, SDE não é para você. É melhor usar um arquivo GeoDatabase.

Quanto às compensações … SDE não é fácil de configurar ou gerenciar. Você tem que usar um RDBMS.

O SDE é destinado a organizações maiores onde um banco de dados é necessário, mas vários usuários precisam acessar e atualizar / editar dados.

Comentários

• Quero dizer, produtos Arc são muito ruins quando se trata de ambientes multiusuário. Parece haver muitas coisas que não podem ' ser feitas enquanto as pessoas estão conectadas. Se o desempenho e o ambiente multiusuário robusto são importantes, é melhor permitir que o RDBMS faça todo o trabalho, não envolvendo um middleware sujo, apenas desacelerando as coisas e travando tudo. Mas parece chique, tenho que admitir, a caixa, quero dizer 🙂
• Concordo com Nicklas. Sua comparação faz sentido dentro do mundo Arc, mas SDE não é muito bom com multiusuários. Um RDBMS espacialmente habilitado como PostGIS tem vantagens nesta área. Você já tentou conceder a um usuário direitos para um conjunto de dados SDE que outra pessoa está visualizando?
• Sim, ' encontrei o problema que você ' re descrevendo com a concessão de privilégios. Não tenho certeza se ' ainda é um problema, pois não ' tive que administrar um SDE GDB em alguns anos. As concessões não devem ser bloqueadas por cadeados. Como o postgres / postgis lida com a edição multiusuário?

Hoje em dia, a maioria dos bancos de dados espaciais permite múltiplos espaciais colunas em uma tabela, enquanto SDE se fixa em uma coluna espacial para uma tabela. Eles também têm dados espaciais integrados com suas ferramentas de gerenciamento de dados flexíveis e poderosas, que faltam SDE, como sachems de usuário, replicação de dados, suporte a SQL e etc.

ESRI SDEBinary tem um desempenho rápido. Se se trata de ST_GEOMETRY, SDE pode não ter o melhor desempenho.