PostGIS vs SQL Server pour les données SIG
J'ai donc récemment commencé dans une nouvelle entreprise et j'ai beaucoup d'utilisateurs d'ArcGIS qui semblent vraiment désireux d'aller de l'avant avec une instance PostGIS pour servir des données à nos clients. Bien que cela ne me pose aucun problème, nous sommes une boutique SQL Server à 95% et une boutique Oracle à 5%. Notre SIG interne actuel fonctionne avec SQL Server et je n'ai pas encore entendu de plaintes.
Je sais que SQL Server a beaucoup de capacités spatiales/géométriques améliorées en 2012, mais y a-t-il des fonctionnalités tueuses dans PostGIS qui méritent d'être introduites dans la nouvelle plate-forme? J'ai essayé de le rechercher mais je ne trouve rien de vraiment approfondi ou ce n'est pas complètement biaisé.
Je veux leur donner les meilleurs outils pour faire leur travail, mais je dois aussi soupeser le fait que j'apprendrai Postgres/SIG dès le début et c'est un voyage en soi.
J'ai travaillé avec Postgres et SQL Server. J'ai trouvé que Postgres était supérieur dans la fonctionnalité SIG. Et pendant que je vais détailler brièvement mes conclusions ci-dessous, je suggère ceci: Donnez-vous un délai bref mais raisonnable pour examiner la solution inconnue par rapport à celle que vous connaissez, avec des objectifs spécifiques à l'esprit. Par exemple, peut-être une période de 2 semaines pour installer et apprendre certaines fonctionnalités spécifiques actuellement utilisées. Si vous constatez que vous êtes bloqué ou manque de fonctionnalités pendant cette période, alors vous savez que ce n'est pas pour vous. C'est un investissement dans la recherche qui élargit votre vision et vous aide à réaliser que vous avez peut-être raté quelque chose que vous ignoriez auparavant, ou simplement à confirmer que votre cours actuel est le bon moment.
En ce qui concerne la base de données, j'ai trouvé que Postgres avait une courbe d'apprentissage plus courte et plus superficielle. La documentation est tout simplement incroyable. SQL Server possède pas mal de documentation, mais je la trouve difficile à lire, avec pas assez d'exemples et de tutoriels.
PostGIS vs SQL Server Spatial est similaire à ce qui précède en ce qui concerne la documentation, mais PostGIS bat le pantalon de SQL Server Spatial en termes de fonctionnalité. Par exemple, Google Maps, et dans une moindre mesure Bing Maps, a récemment ajouté une prise en charge complète de geoJSON à son API de cartes. Eh bien, PostGIS peut facilement retourner un résultat geoJSON directement à partir d'une requête de base de données en utilisant ST_AsGeoJSON () . Ce résultat geoJSON peut ensuite être transmis directement à tout ce qui peut comprendre geoJSON. SQL Server nécessite que vous utilisiez une bibliothèque et un traitement supplémentaires , ou que vous utilisiez ogr2ogr. En outre, PostGIS dispose de plus de 300 fonctions disponibles pour la conversion de données dans et hors de la base de données, par rapport à SQL Server qui en a environ 70-100.
Ayant travaillé avec les capacités SIG des deux systèmes, je suggère ce qui suit:
- Si vous cherchez principalement à stocker et à interroger géométries, leurs capacités sont assez comparables.
- Si vous souhaitez effectuer opérations raster, PostGIS est votre seule option sans plugins tiers tels que ST_Raster d'ArcGIS. SQL Server stockera une image, mais oubliez-la si vous souhaitez effectuer des manipulations raster ou des requêtes.
- Certains contesteraient cela, mais en général, je trouve que SQL Server est plus rapide et plus cohérent. Si toutes les autres choses sont égales, pour un runtime de production, je le préfère.
- PostgreSQL a un dialecte SQL beaucoup plus riche et plus élégant et un processeur de requêtes moins criblé de restrictions arbitraires. En termes de puissance et d'élégance du langage, il n'y a pas de comparaison, pgSQL fait ressembler TSQL au gribouillage de l'enfant. J'ai envisagé d'écrire un livre sur la qualité de Transact SQL comme moyen d'apprendre une bonne conception de langage. :-)
Il me semble que la meilleure base de données n'est pas votre principale préoccupation ici et au lieu de cela, vous avez deux considérations différentes qui s'opposent, à savoir la connaissance commerciale vs les désirs des clients. En fin de compte, ce sera une décision commerciale, pas une décision technique.
De toute évidence, il y a un coût d'opportunité, comme Max l'a noté dans un commentaire. Il n'y a pas de chemin aux alentours. Si vous optez pour la route Postgres, veuillez envisager d'obtenir de l'aide, sous la forme d'un bon accord de conseil, d'un dba chevronné, ou les deux.
Si vos utilisateurs veulent PostGIS, cela peut être un gain net cependant. Combien plus de vos services allez-vous vendre en effectuant le changement? Est-ce que cela en vaudra la peine au niveau des coûts? Ce ne sont pas des décisions qui vont être prises en fonction de la base de données qui est la meilleure à vos yeux ou en termes de spécifications techniques, mais en termes de courbe d'apprentissage et de marketing.