Pracoval jsem se všemi třemi databázemi a provedl jsem mezi nimi migraci, takže doufám, že mohu ještě něco přidat do starého příspěvku. Před deseti lety jsem dostal za úkol vložit velký -- 450 milionů prostorových objektů -- datový soubor z GML do prostorové databáze. Rozhodl jsem se vyzkoušet MySQL a Postgis, v té době nebyl v SQL Server prostorový a měli jsme malou startovací atmosféru, takže se zdálo, že se MySQL hodí. Následně jsem byl zapojen do MySQL, zúčastnil jsem se/mluvil na několika konferencích a byl jsem silně zapojen do beta testování funkcí MySQL, které více vyhovují GIS, které byly nakonec vydány s verzí 5.5. Následně jsem se podílel na migraci našich prostorových dat na Postgis a našich firemních dat (s prostorovými prvky) na SQL Server. Toto jsou moje zjištění.
MySQL
1). Problémy se stabilitou. V průběhu 5 let jsme měli několik problémů s poškozením databáze, které bylo možné opravit pouze spuštěním myismachk na indexovém souboru, což je proces, který může u tabulky se 450 miliony řádků trvat déle než 24 hodin.
2). Až donedávna podporovaly typ prostorových dat pouze tabulky MyISAM. To znamená, že pokud chcete podporu transakcí, máte smůlu. Typ tabulky InnoDB nyní podporuje prostorové typy, ale ne na nich indexy, což vzhledem k typickým velikostem sad prostorových dat není příliš užitečné. Viz http://dev.mysql.com/doc/refman/5.0/en/innodb-restrictions.html Moje zkušenost z návštěvy konferencí byla taková, že prostorová byla do značné míry dodatečná myšlenka – implementovali jsme replikaci, dělení atd. ale nefunguje to s prostorovým. EDIT:V nadcházející verzi 5.7.5 bude InnoDB konečně podporovat indexy na prostorových sloupcích, což znamená, že ACID, cizí klíče a prostorové indexy budou konečně dostupné ve stejném enginu.
3). Prostorová funkčnost je extrémně omezená ve srovnání s prostorovými Postgis i SQL Serverem. Stále neexistuje žádná funkce ST_Union, která působí na celé pole geometrie, což je jeden z dotazů, které spouštím nejčastěji, tj. nemůžete psát:
select attribute, ST_Union(geom) from some_table group by some_attribute
což je velmi užitečné v kontextu GIS. Select ST_Union(geom1, const_geom) from some_table , tj. jedna z geometrií je pevně zakódovaná konstantní geometrie je ve srovnání trochu omezující.
4). Žádná podpora pro rastry. Schopnost provádět kombinovanou vektorovou a rastrovou analýzu v rámci db je velmi užitečná funkce GIS.
5). Žádná podpora převodu z jednoho prostorového referenčního systému do druhého.
6). Od akvizice společností Oracle byl prostorový skutečně pozastaven.
Abychom byli spravedliví k MySQL, podporovala naše webové stránky, WMS a obecné prostorové zpracování po několik let a bylo snadné ji nastavit. Na druhou stranu bylo problémem poškození dat a tím, že jste nuceni používat tabulky MyISAM, se vzdáváte mnoha výhod RDBMS.
Postgis
Vzhledem k problémům, které jsme měli s MySQL, jsme nakonec přešli na Postgis. Klíčové body této zkušenosti byly.
1). Extrémní stabilita. Za 5 let nedošlo k žádnému poškození dat a nyní máme na virtuálních strojích Centos přibližně 25 boxů Postgres/GIS s různým stupněm zatížení.
2). Rychlé tempo vývoje -- rastr, topologie, podpora 3D jsou toho nedávnými příklady.
3). Velmi aktivní komunita. Irc kanál Postgis a seznam adresátů jsou vynikajícími zdroji. Referenční příručka Postgis je také vynikající. http://postgis.net/docs/manual-2.0/
4). Hraje velmi dobře s jinými aplikacemi pod záštitou OSGeo, jako jsou GeoServer a GDAL.
5). Uložené procedury lze psát v mnoha jazycích, kromě výchozího plpgsql, jako je Python nebo R.
5). Postgres je plně vyhovující standard RDBMS, jehož cílem je zůstat blízko standardům ANSI.
6). Podpora okenních funkcí a rekurzivních dotazů -- ne v MySQL, ale v SQL Serveru. Díky tomu bylo psaní složitějších prostorových dotazů čistší.
SQL Server.
Použil jsem pouze prostorovou funkcionalitu SQL Server 2008 a mnoho nepříjemností tohoto vydání – nedostatek podpory pro převody z jednoho CRS do druhého, potřeba přidat do prostorových indexů vlastní parametry – bylo nyní vyřešeno.
1). Protože prostorové objekty na serveru SQL Server jsou v podstatě objekty CLR, syntaxe působí pozpátku. Místo ST_Area(geom) napíšete geom.STArea() a to se stane ještě zřetelnějším, když zřetězíte funkce dohromady. Vypuštění podtržítka v názvech funkcí je pouze menší nepříjemnost.
2). Měl jsem několik neplatných polygonů, které byly akceptovány SQL Serverem, a nedostatek funkce ST_MakeValid to může trochu bolet.
3). Pouze Windows. Obecně jsou produkty Microsoftu (jako ty ESRI) navrženy tak, aby spolu velmi dobře spolupracovaly, ale ne vždy mají jako primární cíl soulad se standardem a interoperabilitu. Pokud provozujete obchod pouze se systémem Windows, není to problém.
AKTUALIZACE :Poté, co jsem si trochu pohrál s SQL Server 2012, mohu říci, že byl výrazně vylepšen. Nyní existuje dobrá funkce ověření geometrie, existuje dobrá podpora pro datový typ Geography, včetně objektu FULL GLOBE, který umožňuje reprezentovat objekty, které zabírají více než jednu hemisféru, a podporu pro složené křivky a kruhové řetězce, což je užitečné pro přesné a kompaktní reprezentace oblouků (a kružnic) mimo jiné. Transformace souřadnic z jednoho CRS do druhého je stále potřeba provádět v knihovnách třetích stran, i když to ve většině aplikací není stopka.
Nepoužil jsem SQL Server s dostatečně velkými datovými sadami, abych mohl porovnat jeden na jednoho s Postgis/MySQL, ale podle toho, co jsem viděl, se funkce chovají správně, a přestože nejsou tak plně vybavené jako Postgis, je to obrovské zlepšení nabídky MySQL. .
Omlouvám se za tak dlouhou odpověď, doufám, že část bolesti a radosti, kterou jsem za ta léta vytrpěla, může někomu pomoci.