Mais

MS SQL Spatial como Armazenamento de Dados Central?

MS SQL Spatial como Armazenamento de Dados Central?


Tenho trabalhado para abrir nossos dados espaciais de um sistema de propriedade para um que possa ser lido por mais produtos (MapGuide, ESRI, gvSIG, Map3D etc ...)

Decidi usar o SQL Spatial porque temos um servidor interno disponível para nós e podemos nos conectar a outros sistemas com bastante facilidade por meio dele.

Antes de começar a usá-lo como nosso armazenamento de dados central, há algo que eu deva estar ciente que pode diminuir significativamente o desempenho?


Minha resposta não é sobre desempenho, mas esteja ciente de que você está limitado aos recursos simples e a um conjunto limitado de consultas SQL espaciais. Não que isso seja necessariamente uma coisa ruim, embora eu tenha rapidamente descoberto que gostaria de algumas das consultas SQL disponíveis, digamos, no Postgres ou no Oracle. Os recursos simples de que realmente gosto, mantendo-o simples, permitem que você siga as boas práticas de banco de dados e transforme seus dados em linhas, polígonos, relacionamentos, o que quiser.


Usa indexação Multi-grid em vez de R-Tree como PostGIS e Oracle.

Não relacionado ao desempenho, mas pode ser importante:

Não suporta transformações de coordenadas.

Há uma pequena diferença na sintaxe SQL. Exemplo:

SELECT * FROM table1 WHERE the_geom.STIntersects (geometry :: STGeomFromText ('POINT (100 100)', 0));

Provavelmente há mais alguns, mas atualmente não consigo me lembrar deles :)


Alguns negativos:

  • como mencionado por Mario, nenhuma ferramenta de projeção embutida significa software adicional (FME ou GDAL são úteis) são necessários para reprojetar dados

  • falta desempenho para algumas consultas espaciais (intersecta / dentro) e os índices espaciais devem ser criados manualmente, embora na próxima versão do Denali tenha aparentemente ocorrido grandes melhorias no desempenho e índices espaciais "auto"

  • sem referência linear (mas pode ser adicionado com código .NET - veja abaixo)

  • falta de comunidade - há um projeto de código aberto relacionado em http://sqlspatialtools.codeplex.com/ com pouca atividade, de modo que os drivers e as ferramentas ficam à mercê dos lançamentos da Microsoft. Não há muitos exemplos de SQL.

  • MapServer e GDAL agora têm drivers do SQL Server 2008, mas eles só foram lançados recentemente - vários anos depois de outros bancos de dados espaciais.

Do lado positivo:

  • integração com .NET. Como o SQL Server permite que o código .NET seja executado no banco de dados, ele permite que a funcionalidade em DLLs e bibliotecas .NET sejam incluídas em visualizações, procedimentos armazenados, gatilhos etc. Bibliotecas como http://projnet.codeplex.com/ podem ser incluído para permitir reprojecções na base de dados.

  • todos os sistemas proprietários incluem drivers / carregadores de SQL Server, etc.

  • muitas organizações já têm DBAs do SQL Server, servidores, processos de backup

  • o SQL Server Management Studio é uma ferramenta muito boa e inclui visualizações espaciais

  • Padrões OGC para métodos espaciais e recursos simples


Se seus dados são armazenados como tipo geográfico em uma escala global, você precisa estar ciente da Limitação do Hemisfério.


Assista o vídeo: Microsoft SQL Server -- How to Improve Interoperability using FME