Jeg har arbejdet med alle tre databaser og lavet migreringer mellem dem, så forhåbentlig kan jeg stadig tilføje noget til et gammelt indlæg. For ti år siden fik jeg til opgave at sætte et stort - 450 millioner rumlige objekter - datasæt fra GML til en rumlig database. Jeg besluttede mig for at prøve MySQL og Postgis, på det tidspunkt var der ingen spatial i SQL Server, og vi havde en lille start-atmosfære, så MySQL så ud til at passe godt. Jeg var efterfølgende involveret i MySQL, jeg deltog/talte ved et par konferencer og var stærkt involveret i betatestningen af de mere GIS-kompatible funktioner i MySQL, der endelig blev udgivet med version 5.5. Jeg har efterfølgende været involveret i at migrere vores geografiske data til Postgis og vores virksomhedsdata (med rumlige elementer) til SQL Server. Dette er mine resultater.
MySQL
1). Stabilitetsproblemer. I løbet af 5 år havde vi adskillige problemer med databasekorruption, som kun kunne løses ved at køre myismachk på indeksfilen, en proces, der kan tage mere end 24 timer på en tabel med 450 millioner rækker.
2). Indtil for nylig understøttede kun MyISAM-tabeller den geografiske datatype. Det betyder, at hvis du ønsker transaktionssupport, er du uheldig. InnoDB-tabeltypen understøtter nu rumlige typer, men ikke indekser på dem, hvilket givet de typiske størrelser af geodatasæt ikke er særlig nyttigt. Se http://dev.mysql.com/doc/refman/5.0/en/innodb-restrictions.html Min erfaring fra at gå til konferencer var, at rumlig var meget en eftertanke -- vi har implementeret replikering, partitionering osv. men det virker ikke med spatial.EDIT:I den kommende 5.7.5-udgivelse vil InnoDB endelig understøtte indekser på rumlige kolonner, hvilket betyder, at ACID, fremmednøgler og rumlige indekser endelig vil være tilgængelige i samme motor.
3). Den rumlige funktionalitet er ekstremt begrænset sammenlignet med både Postgis og SQL Server spatial. Der er stadig ingen ST_Union funktion, der virker på et helt geometrifelt, en af de forespørgsler, jeg kører oftest, dvs. du kan ikke skrive:
select attribute, ST_Union(geom) from some_table group by some_attribute
hvilket er meget nyttigt i en GIS sammenhæng. Select ST_Union(geom1, const_geom) from some_table , dvs. en af geometrierne er en hårdkodet konstant geometri er en smule begrænsende i sammenligning.
4). Ingen støtte til raster. At kunne lave kombineret vektor-raster-analyse inden for en db er meget nyttig GIS-funktionalitet.
5). Ingen understøttelse af konvertering fra et rumligt referencesystem til et andet.
6). Siden opkøbet af Oracle er spatial virkelig blevet sat i bero.
For at være retfærdig over for MySQL understøttede den generelt vores hjemmeside, WMS og generel rumlig behandling i flere år og var nem at konfigurere. På den negative side var datakorruption et problem, og ved at blive tvunget til at bruge MyISAM-tabeller giver du afkald på mange af fordelene ved et RDBMS.
Postgis
I betragtning af de problemer, vi havde med MySQL, konverterede vi i sidste ende til Postgis. Nøglepunkterne i denne oplevelse har været.
1). Ekstrem stabilitet. Ingen datakorruption i 5 år, og vi har nu omkring 25 Postgres/GIS-bokse på centos virtuelle maskiner, under forskellige grader af belastning.
2). Hurtigt udviklingstempo -- raster, topologi, 3D-understøttelse er de seneste eksempler på dette.
3). Meget aktivt fællesskab. Postgis irc-kanalen og mailinglisten er fremragende ressourcer. Postgis referencemanualen er også fremragende. http://postgis.net/docs/manual-2.0/
4). Spiller meget godt med andre applikationer under OSGeo-paraplyen, såsom GeoServer og GDAL.
5). Lagrede procedurer kan skrives på mange sprog, bortset fra standard plpgsql, såsom Python eller R.
5). Postgres er en meget standardkompatibel, fuldt udstyret RDBMS, som har til formål at forblive tæt på ANSI-standarderne.
6). Understøttelse af vinduesfunktioner og rekursive forespørgsler -- ikke i MySQL, men i SQL Server. Dette har gjort det nemmere at skrive mere komplekse rumlige forespørgsler.
SQL-server.
Jeg har kun brugt SQL Server 2008 rumlige funktionalitet, og mange af irritationsmomenterne ved den udgivelse -- manglende understøttelse af konverteringer fra en CRS til en anden, behovet for at tilføje dine egne parametre til rumlige indekser -- er nu blevet løst.
1). Da rumlige objekter i SQL Server grundlæggende er CLR-objekter, føles syntaksen bagvendt. I stedet for ST_Area(geom) skriver man geom.STARea(), og det bliver endnu mere tydeligt, når man kæder funktioner sammen. Sletningen af understregningen i funktionsnavne er blot en mindre irritation.
2). Jeg har haft en række ugyldige polygoner, der er blevet accepteret af SQL Server, og manglen på en ST_MakeValid-funktion kan gøre dette en smule smertefuldt.
3). Kun Windows. Generelt er Microsoft-produkter (som ESRI-produkter) designet til at fungere meget godt sammen, men har ikke altid standardens overholdelse og interoperabilitet som primære mål. Hvis du kører en Windows-butik, er dette ikke et problem.
OPDATERING :efter at have spillet lidt med SQL Server 2012, kan jeg sige, at det er blevet væsentligt forbedret. Der er nu en god geometrivalideringsfunktion, der er god understøttelse af datatypen Geografi, inklusive et FULL GLOBE-objekt, som gør det muligt at repræsentere objekter, der optager mere end én halvkugle, og understøttelse af sammensatte kurver og cirkulære strenge, hvilket er nyttigt til nøjagtig og kompakt repræsentationer af buer (og cirkler) blandt andet. Transformation af koordinater fra et CRS til et andet skal stadig udføres i tredjepartsbiblioteker, selvom dette ikke er en showstopper i de fleste applikationer.
Jeg har ikke brugt SQL Server med store nok datasæt til at sammenligne én til én med Postgis/MySQL, men efter hvad jeg har set funktionerne opføre sig korrekt, og selvom det ikke er helt så fuldt udstyret som Postgis, er det en kæmpe forbedring af MySQL's tilbud .
Undskyld for så langt et svar, jeg håber, at noget af den smerte og glæde, jeg har lidt gennem årene, kan være til hjælp for nogen.