Ik heb met alle drie de databases gewerkt en migraties tussen beide gedaan, dus hopelijk kan ik nog iets toevoegen aan een oud bericht. Tien jaar geleden kreeg ik de taak om een omvangrijke -- 450 miljoen ruimtelijke objecten -- dataset van GML naar een ruimtelijke database te brengen. Ik besloot MySQL en Postgis uit te proberen, in die tijd was er geen ruimte in SQL Server en we hadden een kleine startup-sfeer, dus MySQL leek goed te passen. Vervolgens was ik betrokken bij MySQL, woonde en sprak ik op een aantal conferenties en was nauw betrokken bij het bètatesten van de meer GIS-compatibele functies in MySQL die uiteindelijk met versie 5.5 werd uitgebracht. Vervolgens ben ik betrokken geweest bij het migreren van onze ruimtelijke data naar Postgis en onze corporate data (met ruimtelijke elementen) naar SQL Server. Dit zijn mijn bevindingen.
MijnSQL
1). Stabiliteitsproblemen. In de loop van 5 jaar hadden we verschillende problemen met databasecorruptie, die alleen konden worden opgelost door myismachk op het indexbestand uit te voeren, een proces dat meer dan 24 uur kan duren op een tabel met 450 miljoen rijen.
2). Tot voor kort ondersteunden alleen MyISAM-tabellen het type ruimtelijke gegevens. Dit betekent dat als je transactieondersteuning wilt, je pech hebt. InnoDB-tabeltype ondersteunt nu ruimtelijke typen, maar geen indexen erop, wat gezien de typische grootte van ruimtelijke gegevenssets niet erg handig is. Zie http://dev.mysql.com/doc/refman/5.0/en/innodb-restrictions.html Mijn ervaring met het bezoeken van conferenties was dat ruimtelijk een bijzaak was -- we hebben replicatie, partitionering, enz. geïmplementeerd, maar het werkt niet met ruimtelijke. EDIT:In de komende 5.7.5-release zal InnoDB eindelijk indexen op ruimtelijke kolommen ondersteunen, wat betekent dat ACID, externe sleutels en ruimtelijke indexen eindelijk beschikbaar zullen zijn in dezelfde engine.
3). De ruimtelijke functionaliteit is extreem beperkt in vergelijking met zowel Postgis als ruimtelijke SQL Server. Er is nog steeds geen ST_Union-functie die werkt op een heel geometrieveld, een van de vragen die ik het vaakst uitvoer, dat wil zeggen, je kunt niet schrijven:
select attribute, ST_Union(geom) from some_table group by some_attribute
wat erg handig is in een GIS-context. Select ST_Union(geom1, const_geom) from some_table , dat wil zeggen, een van de geometrieën is een hardgecodeerde constante geometrie, wat in vergelijking een beetje beperkend is.
4). Geen ondersteuning voor rasters. Gecombineerde vector-rasteranalyses kunnen uitvoeren binnen een db is een zeer nuttige GIS-functionaliteit.
5). Geen ondersteuning voor conversie van het ene ruimtelijke referentiesysteem naar het andere.
6). Sinds de overname door Oracle is de ruimte echt on hold gezet.
Over het algemeen heeft MySQL, om eerlijk te zijn, onze website, WMS en algemene ruimtelijke verwerking gedurende meerdere jaren ondersteund en was het eenvoudig in te stellen. Aan de andere kant was datacorruptie een probleem, en door gedwongen te worden om MyISAM-tabellen te gebruiken, geeft u veel van de voordelen van een RDBMS op.
Postgi's
Gezien de problemen die we hadden met MySQL, zijn we uiteindelijk overgestapt op Postgis. De belangrijkste punten van deze ervaring waren.
1). Extreme stabiliteit. Geen gegevenscorruptie in 5 jaar en we hebben nu ongeveer 25 Postgres/GIS-boxen op virtuele centos-machines, onder verschillende mate van belasting.
2). Snelle ontwikkeling -- raster, topologie, 3D-ondersteuning zijn recente voorbeelden hiervan.
3). Zeer actieve gemeenschap. Het irc-kanaal en de mailinglijst van Postgis zijn uitstekende bronnen. De referentiehandleiding van Postgis is ook uitstekend. http://postgis.net/docs/manual-2.0/
4). Speelt heel goed met andere applicaties, onder de OSGeo-paraplu, zoals GeoServer en GDAL.
5). Opgeslagen procedures kunnen in veel talen worden geschreven, behalve de standaard plpgsql, zoals Python of R.
5). Postgres is een zeer standaardconform, volledig uitgerust RDBMS, dat tot doel heeft dicht bij de ANSI-normen te blijven.
6). Ondersteuning voor vensterfuncties en recursieve zoekopdrachten -- niet in MySQL, maar in SQL Server. Dit heeft het schrijven van complexere ruimtelijke queries schoner gemaakt.
SQL-server.
Ik heb alleen ruimtelijke functionaliteit van SQL Server 2008 gebruikt, en veel van de ergernissen van die release -- gebrek aan ondersteuning voor conversies van het ene CRS naar het andere, de noodzaak om je eigen parameters toe te voegen aan ruimtelijke indexen -- zijn nu opgelost.
1). Omdat ruimtelijke objecten in SQL Server in feite CLR-objecten zijn, voelt de syntaxis achterlijk aan. In plaats van ST_Area(geom) schrijf je geom.STArea() en dit wordt nog duidelijker wanneer je functies aan elkaar koppelt. Het weglaten van het onderstrepingsteken in functienamen is slechts een kleine ergernis.
2). Ik heb een aantal ongeldige polygonen gehad die zijn geaccepteerd door SQL Server, en het ontbreken van een ST_MakeValid-functie kan dit een beetje pijnlijk maken.
3). Alleen ramen. Over het algemeen zijn Microsoft-producten (zoals ESRI-producten) ontworpen om heel goed met elkaar samen te werken, maar hebben niet altijd de naleving en interoperabiliteit van de standaard als primaire doelstellingen. Als u een winkel met alleen vensters heeft, is dit geen probleem.
UPDATE :na een beetje met SQL Server 2012 te hebben gespeeld, kan ik zeggen dat het aanzienlijk is verbeterd. Er is nu een goede functie voor het valideren van geometrie, er is goede ondersteuning voor het gegevenstype Geografie, inclusief een FULL GLOBE-object, waarmee objecten kunnen worden weergegeven die meer dan één halfrond beslaan, en ondersteuning voor samengestelde curven en cirkelvormige tekenreeksen, wat handig is voor nauwkeurige en compacte voorstellingen van onder andere bogen (en cirkels). Het transformeren van coördinaten van het ene CRS naar het andere moet nog worden gedaan in bibliotheken van derden, hoewel dit in de meeste toepassingen geen showstopper is.
Ik heb SQL Server niet gebruikt met datasets die groot genoeg zijn om één op één te vergelijken met Postgis/MySQL, maar van wat ik heb gezien, gedragen de functies zich correct, en hoewel niet zo volledig uitgerust als Postgis, is het een enorme verbetering ten opzichte van het aanbod van MySQL .
Sorry voor zo'n lang antwoord, ik hoop dat een deel van de pijn en vreugde die ik in de loop der jaren heb geleden, iemand kan helpen.