J'ai travaillé avec les trois bases de données et effectué des migrations entre elles, alors j'espère pouvoir encore ajouter quelque chose à un ancien message. Il y a dix ans, j'ai été chargé de placer un ensemble de données assez important - 450 millions d'objets spatiaux - de GML dans une base de données spatiale. J'ai décidé d'essayer MySQL et Postgis, à l'époque il n'y avait pas d'espace dans SQL Server et nous avions une petite atmosphère de startup, donc MySQL semblait bien convenir. J'ai ensuite été impliqué dans MySQL, j'ai assisté/parlé à quelques conférences et j'ai été fortement impliqué dans les tests bêta des fonctions les plus conformes au SIG de MySQL qui ont finalement été publiées avec la version 5.5. J'ai ensuite été impliqué dans la migration de nos données spatiales vers Postgis et de nos données d'entreprise (avec des éléments spatiaux) vers SQL Server. Ce sont mes découvertes.
MySQL
1). Problèmes de stabilité. Au cours de 5 ans, nous avons eu plusieurs problèmes de corruption de base de données, qui ne pouvaient être résolus qu'en exécutant myismachk sur le fichier d'index, un processus qui peut prendre plus de 24 heures sur une table de 450 millions de lignes.
2). Jusqu'à récemment, seules les tables MyISAM prenaient en charge le type de données spatiales. Cela signifie que si vous souhaitez une assistance pour les transactions, vous n'avez pas de chance. Le type de table InnoDB prend désormais en charge les types spatiaux, mais pas les index sur ceux-ci, ce qui, compte tenu des tailles typiques des ensembles de données spatiales, n'est pas très utile. Voir http://dev.mysql.com/doc/refman/5.0/en/innodb-restrictions.html Mon expérience d'aller à des conférences était que le spatial était vraiment une réflexion après coup - nous avons implémenté la réplication, le partitionnement, etc. mais cela ne fonctionne pas avec spatial.EDIT :dans la prochaine version 5.7.5, InnoDB prendra enfin en charge les index sur les colonnes spatiales, ce qui signifie que l'ACID, les clés étrangères et les index spatiaux seront enfin disponibles dans le même moteur.
3). La fonctionnalité spatiale est extrêmement limitée par rapport à la fois à Postgis et à SQL Server spatial. Il n'y a toujours pas de fonction ST_Union qui agit sur un champ géométrique entier, l'une des requêtes que j'exécute le plus souvent, c'est-à-dire que vous ne pouvez pas écrire :
select attribute, ST_Union(geom) from some_table group by some_attribute
ce qui est très utile dans un contexte SIG. Select ST_Union(geom1, const_geom) from some_table , c'est-à-dire que l'une des géométries est une géométrie constante codée en dur est un peu limitative en comparaison.
4). Pas de support pour les rasters. Pouvoir effectuer une analyse combinée vecteur-raster dans une base de données est une fonctionnalité SIG très utile.
5). Aucune prise en charge de la conversion d'un système de référence spatiale à un autre.
6). Depuis l'acquisition par Oracle, le spatial a vraiment été mis en veilleuse.
Dans l'ensemble, pour être juste envers MySQL, il a pris en charge notre site Web, WMS et le traitement spatial général pendant plusieurs années, et a été facile à configurer. En revanche, la corruption des données était un problème, et en étant obligé d'utiliser des tables MyISAM, vous renoncez à de nombreux avantages d'un SGBDR.
Postgis
Compte tenu des problèmes que nous avions avec MySQL, nous nous sommes finalement convertis à Postgis. Les points clés de cette expérience ont été.
1). Stabilité extrême. Aucune corruption de données en 5 ans et nous avons maintenant environ 25 boîtiers Postgres/GIS sur des machines virtuelles centos, sous divers degrés de charge.
2). Rythme de développement rapide -- raster, topologie, prise en charge 3D en sont des exemples récents.
3). Communauté très active. Le canal irc et la liste de diffusion Postgis sont d'excellentes ressources. Le manuel de référence Postgis est également excellent. http://postgis.net/docs/manual-2.0/
4). Joue très bien avec d'autres applications, sous l'égide de l'OSGeo, telles que GeoServer et GDAL.
5). Les procédures stockées peuvent être écrites dans de nombreux langages, à l'exception du plpgsql par défaut, tel que Python ou R.
5). Postgres est un SGBDR très conforme aux normes et complet, qui vise à rester proche des normes ANSI.
6). Prise en charge des fonctions de fenêtre et des requêtes récursives - pas dans MySQL, mais dans SQL Server. Cela a rendu l'écriture de requêtes spatiales plus complexes plus propre.
SQL Server.
Je n'ai utilisé que la fonctionnalité spatiale de SQL Server 2008, et bon nombre des désagréments de cette version - manque de prise en charge des conversions d'un CRS à un autre, nécessité d'ajouter vos propres paramètres aux index spatiaux - ont maintenant été résolus.
1). Comme les objets spatiaux dans SQL Server sont essentiellement des objets CLR, la syntaxe semble inversée. Au lieu de ST_Area(geom), vous écrivez geom.STArea() et cela devient encore plus évident lorsque vous enchaînez des fonctions. La suppression du trait de soulignement dans les noms de fonction n'est qu'un désagrément mineur.
2). J'ai eu un certain nombre de polygones invalides qui ont été acceptés par SQL Server, et l'absence d'une fonction ST_MakeValid peut rendre cela un peu pénible.
3). Windows seulement. En général, les produits Microsoft (comme ceux d'ESRI) sont conçus pour fonctionner très bien les uns avec les autres, mais n'ont pas toujours la conformité aux normes et l'interopérabilité comme objectifs principaux. Si vous gérez une boutique Windows uniquement, ce n'est pas un problème.
MISE À JOUR :après avoir joué un peu avec SQL Server 2012, je peux dire qu'il s'est considérablement amélioré. Il y a maintenant une bonne fonction de validation de la géométrie, il y a un bon support pour le type de données Geography, y compris un objet FULL GLOBE, qui permet de représenter des objets qui occupent plus d'un hémisphère et un support pour les courbes composées et les chaînes circulaires, ce qui est utile pour précis et compact représentations d'arcs (et de cercles) entre autres. La transformation des coordonnées d'un CRS à un autre doit encore être effectuée dans des bibliothèques tierces, bien que ce ne soit pas un obstacle dans la plupart des applications.
Je n'ai pas utilisé SQL Server avec des ensembles de données suffisamment volumineux pour comparer un à un avec Postgis/MySQL, mais d'après ce que j'ai vu, les fonctions se comportent correctement, et bien qu'elles ne soient pas aussi complètes que Postgis, c'est une énorme amélioration sur les offres de MySQL .
Désolé pour une si longue réponse, j'espère qu'une partie de la douleur et de la joie que j'ai subies au fil des ans pourra aider quelqu'un.
