PostgreSQL vs. MySQL: comparaison des fonctionnalités spatiales

Nous sommes en train de construire une application web qui a une composante de données spatiales. Au début, nos comparaisons de données spatiales prendront un point donné et retourneront des polygones spatiaux superposés assortis.

Cela étant dit, notre base de données comporte de nombreux autres composants qui incluent toutes les choses typiques que vous trouverez dans votre base de données relationnelle générale.

Nous sommes au point de notre projet où nous devons choisir la solution de base de données à utiliser.

Tous les membres du projet connaissent mieux l'implémentation et l'administration de MySQL, mais toutes les recherches suggèrent que PostgreSQL est la meilleure solution - en particulier en ce qui concerne les données spatiales utilisant postGIS.

Nous espérons (espérons) que notre application connaîtra beaucoup d'action avec beaucoup d'utilisateurs simultanés.

Est-ce que toute personne ayant une expérience de l'utilisation de MySQL comme SGBDR avec un composant de données spatiales a des conseils / expériences à long terme?

Y a-t-il des inconvénients à utiliser PostGIS à l'exception de la familiarité?

Je ne peux pas parler des avantages / inconvénients par rapport à MySQL, mais le code PostGIS est assez largement considéré comme l'un des meilleurs (en termes de vitesse / fonctionnalité) et le plus mature (en termes de tests / exposition dans le monde réel) ) disponible.

À titre d'exemple, certains membres de la FAA ont discuté au PGEast 2010 de la conversion de leur base de données aéroportuaire (utilisée par AeroNav et d'autres pour compiler des cartes) en Postgres / PostGIS d'Oracle.
Le site avationDB est également construit au-dessus de Postgres (8.0).

Si les requêtes liées aux SIG sont au cœur de ce que vous faites, ma suggestion serait d'aller avec Postgres. Il peut également gérer tout ce que vous feriez normalement dans une base de données relationnelle.

En ce qui concerne le passage de MySQL, la documentation derrière Postgres est de premier ordre, et il y a aussi une section du wiki Oostgres sur le passage de MySQL à Postgres .
La courbe d'apprentissage initiale peut être un peu raide et vous devrez peut-être modifier votre base de données et toutes les procédures stockées (si vous les avez déjà écrites pour MySQL), mais ce n'est pas une tâche insurmontable.

Vous devriez être en mesure d'en ramasser suffisamment pour effectuer le changement dans quelques semaines, et si vous configurez une base de données de développement, vous pouvez probablement bien maîtriser les tâches de routine en un mois et être sûr de savoir où chercher dans le manuel pour les moins habituels.

En parlant de choses très importantes. Voici une liste des éléments pris en charge par PostGIS qui sont totalement absents dans MySQL et MariaDB.

• SRID dans les calculs, donnez à vos points un SRID différent et vous obtiendrez différentes valeurs. Il s'agit de fonctions d'agrégation: à ma connaissance, MySQL ne propose aucune fonction d'agrégation spatiale.

K voisin le plus proche: seul PostGIS prend en charge KNN. Trouvez le point le plus proche de n'importe quel point en utilisant juste un index: pas besoin de calculer la distance de tous les points! Er. MySQL rompt les spécifications et vérifie uniquement que deux valeurs ont le même SRID. PostGIS est livré avec une base de données de définitions pro4j pour permettre une reconnaissance transparente du SRID. La définition d'un SRID et l'appel ST_Transform( une fonction manquante à MySQL ) reprojeteront vos coordonnées.

Dans MySQL, tous les calculs sont effectués en supposant SRID 0, quelle que soit la valeur SRID réelle. SRID 0 représente un plan cartésien plat infini sans unité affectée à ses axes. À l'avenir, les calculs peuvent utiliser les valeurs SRID spécifiées. Pour garantir le comportement SRID 0, créez des valeurs de géométrie à l'aide de SRID 0. SRID 0 est la valeur par défaut pour les nouvelles valeurs de géométrie si aucun SRID n'est spécifié.

• Rasters : il y a une tonne de fonctionnalités ici, de la génération du raster à l'extraction. Vous pouvez générer des heatmaps et similaires.

• Géographie , PostGIS prend en charge un type de géographie non projeté qui n'utilise pas du tout les mathématiques cartésiennes. Il a toute une série de fonctions associées qui opèrent sur des sphéroïdes oblates. Inversement, MySQL ne peut même pas créer un cadre de délimitation dans un SRS géographique à partir de deux points.

• Topologie , distincte des géométries vectorielles, les géomètres topo stockent les nœuds et les relations. Déplacez un nœud, le bord bouge aussi et vous obtenez une nouvelle face. Cela oblige également à orienter les bords, ce qui les rend idéaux pour le routage. En tant que sous-point, 100% de ce que fait PgRouting n'est pas disponible pour MySQL - vous ne pouvez donc pas créer de carte Google Maps ou similaire par-dessus.

• Géocodage: il existe une extension du géocodeur dans le répertoire contrib qui fonctionne à partir des données du recensement, et un chargeur pour installer ces données.

• Normalisation des adresses: il existe une extension qui gère la normalisation des adresses pour une analyse, un stockage et une comparaison faciles.

• Fonctionnalités SQL-MM , vous ne trouverez tout simplement pas CIRCULARSTRING COMPOUNDCURVE CURVEPOLYGON MULTICURVEou MULTISURFACEdans MySQL.

• nd cords: PostGIS peut prendre en charge les formes et les points 3dm, 3dz et 4d que MySQL ne peut tout simplement pas

• MySQL ne prend en charge que les index r-tree. PostGIS prend en charge r-tree (gist / gin) et BRIN (pour les grandes tables de géométrie)

• Fonctions d'agrégation: à ma connaissance, MySQL ne propose aucune fonction d'agrégation spatiale

• K voisin le plus proche: seul PostGIS prend en charge KNN . Trouvez le point le plus proche de n'importe quel point en utilisant juste un index: pas besoin de calculer la distance de tous les points!

• Indexage. PostgreSQL vous permet de stocker toutes les données sur votre index spatial (qui est un index gist / gin). Par exemple, vous pouvez stocker les year(ou d'autres données non spatiales) et les geomsur le même index. Voir btree_ginet btree_gistpour plus d'informations sur la façon de procéder.

En outre, PostGIS prend probablement en charge environ 200 fonctions ou plus .

En bref, MySQL ne tient pas à PostGIS et il le sait. PostGIS est une bête. Je voulais juste expliquer certaines de ces choses.

Je suis totalement d'accord avec toutes les déclarations de la première réponse, mais partageant ma propre expérience - je l'ai fait sur l'administration nationale des routes de mon pays: critique de production, site à fort trafic. Je suggère qu'une application web soit alimentée par MySQL et PostgreSQL / PostGIS.

Pour tous les trucs "typiques", l'application Web fonctionne parfaitement avec un CMS basé sur MySQL. Pour toutes les tâches spatiales, la même application Web fonctionne également parfaitement;) avec un développement personnalisé basé sur PostgreSQL / PostGIS. Le premier composant a été développé et est maintenu sans effort avec les compétences normales de MySQL. La deuxième composante impliquait un peu plus d'efforts de recherche au début.

Vous n'avez pas besoin de forcer une implémentation coûteuse complète de choses typiques dans le PostgreSQL / PostGIS pas si familier et vous n'avez pas non plus à forcer une implémentation sous-optimale des choses géospatiales dans MySQL. Laissez chaque joueur jouer là où il peut frapper.