Ich habe mit allen drei Datenbanken gearbeitet und Migrationen zwischen ihnen durchgeführt, also kann ich hoffentlich noch etwas zu einem alten Beitrag hinzufügen. Vor zehn Jahren wurde ich damit beauftragt, einen umfangreichen – 450 Millionen räumliche Objekte – Datensatz von GML in eine räumliche Datenbank zu übertragen. Ich beschloss, MySQL und Postgis auszuprobieren, da es zu der Zeit in SQL Server keine räumlichen Gegebenheiten gab und wir eine kleine Startup-Atmosphäre hatten, schien MySQL gut zu passen. Danach war ich an MySQL beteiligt, ich nahm an einigen Konferenzen teil/sprach auf ihnen und war stark an den Beta-Tests der GIS-kompatibleren Funktionen in MySQL beteiligt, die schließlich mit Version 5.5 veröffentlicht wurden. Anschließend war ich an der Migration unserer räumlichen Daten nach Postgis und unserer Unternehmensdaten (mit räumlichen Elementen) nach SQL Server beteiligt. Das sind meine Erkenntnisse.
MySQL
1). Stabilitätsprobleme. Im Laufe von 5 Jahren hatten wir mehrere Probleme mit Datenbankbeschädigungen, die nur behoben werden konnten, indem myismachk auf der Indexdatei ausgeführt wurde, ein Vorgang, der bei einer Tabelle mit 450 Millionen Zeilen weit über 24 Stunden dauern kann.
2). Bis vor kurzem unterstützten nur MyISAM-Tabellen den räumlichen Datentyp. Das bedeutet, wenn Sie Transaktionsunterstützung wünschen, haben Sie Pech. Der InnoDB-Tabellentyp unterstützt jetzt räumliche Typen, aber keine Indizes darauf, was angesichts der typischen Größe von räumlichen Datensätzen nicht besonders nützlich ist. Siehe http://dev.mysql.com/doc/refman/5.0/en/innodb-restrictions.html. Meine Erfahrung auf Konferenzen war, dass räumliche Gegebenheiten eher ein nachträglicher Einfall waren – wir haben Replikation, Partitionierung usw. aber es funktioniert nicht mit Spatial. EDIT:In der kommenden Version 5.7.5 wird InnoDB endlich Indizes auf Spatial-Spalten unterstützen, was bedeutet, dass ACID, Fremdschlüssel und Spatial-Indizes endlich in derselben Engine verfügbar sein werden.
3). Die Spatial-Funktionalität ist im Vergleich zu Postgis und SQL Server Spatial extrem eingeschränkt. Es gibt immer noch keine ST_Union-Funktion, die auf ein gesamtes Geometriefeld wirkt, eine der Abfragen, die ich am häufigsten ausführe, dh Sie können nicht schreiben:
select attribute, ST_Union(geom) from some_table group by some_attribute
was im GIS-Kontext sehr nützlich ist. Select ST_Union(geom1, const_geom) from some_table , dh eine der Geometrien ist eine hartcodierte konstante Geometrie, ist im Vergleich etwas einschränkend.
4). Keine Unterstützung für Raster. Kombinierte Vektor-Raster-Analysen innerhalb einer Datenbank durchführen zu können, ist eine sehr nützliche GIS-Funktionalität.
5). Keine Unterstützung für die Konvertierung von einem Raumbezugssystem in ein anderes.
6). Seit der Übernahme durch Oracle wurde Spatial wirklich auf Eis gelegt.
Insgesamt, um fair zu MySQL zu sein, unterstützte es unsere Website, WMS und die allgemeine räumliche Verarbeitung für mehrere Jahre und war einfach einzurichten. Auf der anderen Seite war die Datenbeschädigung ein Problem, und durch die Notwendigkeit, MyISAM-Tabellen zu verwenden, geben Sie viele der Vorteile eines RDBMS auf.
Postgis
Angesichts der Probleme, die wir mit MySQL hatten, haben wir letztendlich auf Postgis umgestellt. Die wichtigsten Punkte dieser Erfahrung waren.
1). Extreme Stabilität. Keine Datenbeschädigung in 5 Jahren und wir haben jetzt etwa 25 Postgres/GIS-Boxen auf virtuellen Centos-Maschinen mit unterschiedlicher Auslastung.
2). Rasantes Entwicklungstempo – Raster, Topologie, 3D-Unterstützung sind aktuelle Beispiele dafür.
3). Sehr aktive Community. Der IRC-Kanal und die Mailingliste von Postgis sind hervorragende Ressourcen. Das Postgis-Referenzhandbuch ist ebenfalls ausgezeichnet. http://postgis.net/docs/manual-2.0/
4). Spielt sehr gut mit anderen Anwendungen unter dem Dach von OSGeo, wie GeoServer und GDAL.
5). Gespeicherte Prozeduren können in vielen Sprachen geschrieben werden, abgesehen von der Standardsprache plpgsql, wie Python oder R.
5). Postgres ist ein sehr standardkonformes, voll ausgestattetes RDBMS, das darauf abzielt, nahe an den ANSI-Standards zu bleiben.
6). Unterstützung für Fensterfunktionen und rekursive Abfragen – nicht in MySQL, aber in SQL Server. Dadurch wurde das Schreiben komplexerer räumlicher Abfragen übersichtlicher.
SQL-Server.
Ich habe nur die Spatial-Funktionalität von SQL Server 2008 verwendet, und viele der Ärgernisse dieser Version – fehlende Unterstützung für Konvertierungen von einem CRS in ein anderes, die Notwendigkeit, eigene Parameter zu Spatial-Indizes hinzuzufügen – wurden jetzt behoben.
1). Da räumliche Objekte in SQL Server im Grunde CLR-Objekte sind, fühlt sich die Syntax rückwärts an. Anstelle von ST_Area(geom) schreiben Sie geom.STArea() und dies wird noch deutlicher, wenn Sie Funktionen miteinander verketten. Das Weglassen des Unterstrichs in Funktionsnamen ist nur ein kleines Ärgernis.
2). Ich hatte eine Reihe von ungültigen Polygonen, die von SQL Server akzeptiert wurden, und das Fehlen einer ST_MakeValid-Funktion kann dies etwas schmerzhaft machen.
3). Nur Windows. Im Allgemeinen sind Microsoft-Produkte (wie die von ESRI) so konzipiert, dass sie sehr gut miteinander funktionieren, haben aber nicht immer die Einhaltung von Standards und Interoperabilität als primäre Ziele. Wenn Sie einen reinen Windows-Shop betreiben, ist dies kein Problem.
AKTUALISIEREN :Nachdem ich ein wenig mit SQL Server 2012 gespielt habe, kann ich sagen, dass es erheblich verbessert wurde. Es gibt jetzt eine gute Geometrie-Validierungsfunktion, es gibt gute Unterstützung für den Geographie-Datentyp, einschließlich eines FULL GLOBE-Objekts, das die Darstellung von Objekten ermöglicht, die mehr als eine Hemisphäre einnehmen, und Unterstützung für zusammengesetzte Kurven und kreisförmige Zeichenfolgen, was für Genauigkeit und Kompaktheit nützlich ist Darstellungen von Bögen (und Kreisen) unter anderem. Das Umwandeln von Koordinaten von einem CRS in ein anderes muss immer noch in Bibliotheken von Drittanbietern durchgeführt werden, obwohl dies in den meisten Anwendungen kein Showstopper ist.
Ich habe SQL Server nicht mit ausreichend großen Datensätzen verwendet, um sie eins zu eins mit Postgis/MySQL zu vergleichen, aber wie ich gesehen habe, verhalten sich die Funktionen korrekt, und obwohl sie nicht ganz so umfassend ausgestattet sind wie Postgis, ist dies eine enorme Verbesserung der Angebote von MySQL .
Tut mir leid für eine so lange Antwort, ich hoffe, dass etwas von dem Schmerz und der Freude, die ich im Laufe der Jahre erlitten habe, jemandem helfen könnte.
