MS SQL Spatial comme magasin de données central?

J'ai travaillé sur l'ouverture de nos données spatiales d'un système de propriété à un qui peut être lu par plus de produits (MapGuide, ESRI, gvSIG, Map3D etc ....)

J'ai décidé d'utiliser SQL Spatial car nous avons un serveur en interne à notre disposition et nous pouvons assez facilement le relier à d'autres systèmes.

Avant de commencer à l'utiliser comme notre banque de données centrale, y a-t-il quelque chose dont je devrais être conscient qui pourrait considérablement réduire les performances?

Ma réponse ne concerne pas les performances, mais sachez que vous êtes limité aux fonctionnalités simples et à un ensemble limité de requêtes SQL spatiales. Non pas que ce soit nécessairement une mauvaise chose, bien que je me sois rapidement rendu compte de certaines des requêtes SQL disponibles dans Postgres ou Oracle. Les fonctionnalités simples que j'aime réellement, en restant simple, vous permettent de suivre les bonnes pratiques de base de données et de transformer vos données en lignes, polygones, relations, tout ce que vous voulez.

Utilise l'indexation multi-grille plutôt que R-Tree comme PostGIS et Oracle.

Pas lié aux performances mais peut-être important:

Ne prend pas en charge les transformations de coordonnées.

Il y a une légère différence dans la syntaxe SQL. Exemple:

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

Il y en a probablement plus mais actuellement je ne peux pas m'en souvenir :)

Quelques points négatifs:

• comme mentionné par Mario mentionné aucun outil de projection intégré signifie que des logiciels supplémentaires (FME ou GDAL sont utiles) sont nécessaires pour reprojeter des données

• les performances font défaut pour certaines requêtes spatiales (intersections / à l'intérieur) et les index spatiaux doivent être créés manuellement, bien que dans la prochaine version de Denali, il y ait apparemment eu de grandes améliorations des performances et des index spatiaux "auto"

• pas de référencement linéaire (mais peut être ajouté avec du code .NET - voir ci-dessous)

• manque de communauté - il y a un projet open source connexe sur http://sqlspatialtools.codeplex.com/ avec peu d'activité donc les pilotes et les outils sont à la merci des versions de Microsoft. Pas trop d'exemples SQL.

• MapServer et GDAL ont maintenant tous deux des pilotes SQL Server 2008, mais ceux-ci ne sont sortis que récemment - plusieurs années après d'autres bases de données spatiales.

Du coté positif:

• intégration avec .NET. Comme SQL Server autorise l'exécution de code .NET dans la base de données, il permet d'inclure des fonctionnalités dans les DLL et les bibliothèques .NET dans les vues, les procédures stockées, les déclencheurs, etc. Des bibliothèques telles que http://projnet.codeplex.com/ peuvent être inclus pour permettre les reprojections dans la base de données.

• les systèmes propriétaires incluent tous des pilotes / chargeurs SQL Server, etc.

• de nombreuses organisations ont déjà des DBA SQL Server, des serveurs et des processus de sauvegarde

• SQL Server Management Studio est un très bel outil, et comprend des visualisations spatiales

• Normes OGC pour les méthodes spatiales et les fonctionnalités simples

Si vos données sont stockées en tant que type géographique à l'échelle mondiale, vous devez être conscient de la limitation de l' hémisphère .