Jag har arbetat med alla tre databaserna och gjort migreringar mellan dem, så förhoppningsvis kan jag fortfarande lägga till något i ett gammalt inlägg. För tio år sedan fick jag i uppdrag att lägga ett stort - 450 miljoner rumsliga objekt - dataset från GML till en rumslig databas. Jag bestämde mig för att prova MySQL och Postgis, då fanns det ingen spatial i SQL Server och vi hade en liten startatmosfär, så MySQL verkade passa bra. Jag var sedan involverad i MySQL, jag deltog/talade vid ett par konferenser och var starkt involverad i betatesten av de mer GIS-kompatibla funktionerna i MySQL som slutligen släpptes med version 5.5. Jag har därefter varit involverad i att migrera vår rumsliga data till Postgis och vår företagsdata (med rumsliga element) till SQL Server. Det här är mina upptäckter.
MySQL
1). Stabilitetsfrågor. Under loppet av 5 år hade vi flera problem med databaskorruption, som bara kunde åtgärdas genom att köra myismachk på indexfilen, en process som kan ta långt över 24 timmar på en tabell med 450 miljoner rader.
2). Fram till nyligen stödde endast MyISAM-tabeller den rumsliga datatypen. Det betyder att om du vill ha transaktionsstöd har du ingen tur. InnoDB-tabelltypen stöder nu rumsliga typer, men inte index på dem, vilket med tanke på de typiska storlekarna på rumsliga datamängder inte är särskilt användbart. Se http://dev.mysql.com/doc/refman/5.0/en/innodb-restrictions.html Min erfarenhet från att gå på konferenser var att spatial i hög grad var en eftertanke -- vi har implementerat replikering, partitionering, etc, men det fungerar inte med spatial.EDIT:I den kommande versionen av 5.7.5 kommer InnoDB äntligen att stödja index på rumsliga kolumner, vilket betyder att ACID, främmande nycklar och rumsliga index äntligen kommer att finnas tillgängliga i samma motor.
3). Den rumsliga funktionaliteten är extremt begränsad jämfört med både Postgis och SQL Server spatial. Det finns fortfarande ingen ST_Union-funktion som verkar på ett helt geometrifält, en av de frågor jag kör oftast, dvs du kan inte skriva:
select attribute, ST_Union(geom) from some_table group by some_attribute
vilket är mycket användbart i ett GIS-sammanhang. Select ST_Union(geom1, const_geom) from some_table , dvs en av geometrierna är en hårdkodad konstant geometri är lite begränsande i jämförelse.
4). Inget stöd för raster. Att kunna göra kombinerad vektor-rasteranalys inom en db är mycket användbar GIS-funktionalitet.
5). Inget stöd för konvertering från ett rumsligt referenssystem till ett annat.
6). Sedan förvärvet av Oracle har spatial verkligen lagts på is.
Sammantaget, för att vara rättvis mot MySQL, stödde den vår webbplats, WMS och allmän rumslig bearbetning i flera år, och var lätt att ställa in. På minussidan var datakorruption ett problem, och genom att tvingas använda MyISAM-tabeller ger du upp många av fördelarna med ett RDBMS.
Postgis
Med tanke på problemen vi hade med MySQL konverterade vi till slut till Postgis. De viktigaste punkterna i denna erfarenhet har varit.
1). Extrem stabilitet. Ingen datakorruption på 5 år och vi har nu cirka 25 Postgres/GIS-boxar på centos virtuella maskiner, under varierande belastning.
2). Snabb utvecklingstakt -- raster, topologi, 3D-stöd är de senaste exempel på detta.
3). Mycket aktiv gemenskap. Postgis irc-kanal och e-postlista är utmärkta resurser. Postgis referensmanual är också utmärkt. http://postgis.net/docs/manual-2.0/
4). Spelar mycket bra med andra applikationer, under OSGeo-paraplyet, som GeoServer och GDAL.
5). Lagrade procedurer kan skrivas på många språk, förutom standard plpgsql, som Python eller R.
5). Postgres är ett mycket standardkompatibelt, fullt utrustat RDBMS, som syftar till att hålla sig nära ANSI-standarderna.
6). Stöd för fönsterfunktioner och rekursiva frågor -- inte i MySQL, utan i SQL Server. Detta har gjort att skriva mer komplexa rumsliga frågor renare.
SQL-server.
Jag har bara använt rumslig funktionalitet i SQL Server 2008, och många av irritationsmomenten med den versionen -- brist på stöd för konverteringar från en CRS till en annan, behovet av att lägga till dina egna parametrar till rumsliga index -- har nu lösts.
1). Eftersom rumsliga objekt i SQL Server i grunden är CLR-objekt känns syntaxen bakåtvänd. Istället för ST_Area(geom) skriver man geom.STARea() och detta blir ännu mer uppenbart när man länkar ihop funktioner. Att tappa understrecket i funktionsnamn är bara ett mindre irritationsmoment.
2). Jag har haft ett antal ogiltiga polygoner som har accepterats av SQL Server, och avsaknaden av en ST_MakeValid-funktion kan göra detta lite smärtsamt.
3). Endast Windows. I allmänhet är Microsoft-produkter (som ESRI-produkter) utformade för att fungera mycket bra med varandra, men har inte alltid standardens överensstämmelse och interoperabilitet som primära mål. Om du driver en Windows-butik är detta inget problem.
UPPDATERA :efter att ha spelat lite med SQL Server 2012 kan jag säga att det har förbättrats avsevärt. Det finns nu en bra geometrivalideringsfunktion, det finns bra stöd för datatypen Geografi, inklusive ett FULL GLOBE-objekt, som gör det möjligt att representera objekt som upptar mer än en halvklot och stöd för sammansatta kurvor och cirkulära strängar, vilket är användbart för exakt och kompakt representationer av bågar (och cirklar) bland annat. Transformering av koordinater från ett CRS till ett annat måste fortfarande göras i tredje parts bibliotek, även om detta inte är en showstoppare i de flesta applikationer.
Jag har inte använt SQL Server med tillräckligt stora datamängder för att jämföra en mot en med Postgis/MySQL, men vad jag har sett fungerar funktionerna korrekt, och även om det inte är fullt så fullt utbyggt som Postgis, är det en enorm förbättring av MySQL:s erbjudanden .
Förlåt för ett så långt svar, jag hoppas att en del av den smärta och glädje jag har lidit under åren kan vara till hjälp för någon.