Работил съм и с трите бази данни и съм извършил миграции между тях, така че се надявам, че все още мога да добавя нещо към стара публикация. Преди десет години бях натоварен със задачата да поставя голям - 450 милиона пространствени обекта - набор от данни от GML в пространствена база данни. Реших да изпробвам MySQL и Postgis, по това време нямаше пространствено пространство в SQL Server и имахме малка стартова атмосфера, така че MySQL изглеждаше подходящ. Впоследствие участвах в MySQL, присъствах/говорех на няколко конференции и участвах активно в бета тестването на по-съвместимите с GIS функции в MySQL, която най-накрая беше пусната с версия 5.5. Впоследствие участвах в мигрирането на нашите пространствени данни към Postgis и нашите корпоративни данни (с пространствени елементи) към SQL Server. Това са моите констатации.
MySQL
1). Проблеми със стабилността. В продължение на 5 години имахме няколко проблема с повреда на базата данни, които можеха да бъдат отстранени само чрез стартиране на myismachk в индексния файл, процес, който може да отнеме повече от 24 часа в таблица от 450 милиона редове.
2). Доскоро само таблиците MyISAM поддържаха типа пространствени данни. Това означава, че ако искате подкрепа за транзакции, нямате късмет. Типът таблица InnoDB вече поддържа пространствени типове, но не и индекси върху тях, което като се има предвид типичните размери на наборите от пространствени данни, не е много полезно. Вижте http://dev.mysql.com/doc/refman/5.0/en/innodb-restrictions.html Моят опит от ходенето на конференции беше, че пространственото е много закъсняло – ние приложихме репликация, разделяне и т.н., но не работи с spatial.EDIT:В предстоящата версия 5.7.5 InnoDB най-накрая ще поддържа индекси на пространствени колони, което означава, че ACID, външни ключове и пространствени индекси най-накрая ще бъдат налични в същия двигател.
3). Пространствената функционалност е изключително ограничена в сравнение с Postgis и SQL Server spatial. Все още няма функция ST_Union, която да действа върху цялото поле на геометрията, една от заявките, които изпълнявам най-често, т.е. не можете да пишете:
select attribute, ST_Union(geom) from some_table group by some_attribute
което е много полезно в контекста на ГИС. Select ST_Union(geom1, const_geom) from some_table , т.е. една от геометриите е твърдо кодирана постоянна геометрия, която е малко ограничаваща в сравнение.
4). Няма поддръжка за растери. Възможността за извършване на комбиниран векторно-растерен анализ в рамките на db е много полезна функционалност на ГИС.
5). Няма поддръжка за преобразуване от една пространствена референтна система в друга.
6). След придобиването от Oracle, Spatial наистина беше задържан.
Като цяло, за да бъдем честни към MySQL, той поддържаше нашия уебсайт, WMS и обща пространствена обработка в продължение на няколко години и беше лесен за настройка. От друга страна, повредата на данните беше проблем и като сте принудени да използвате MyISAM таблици, вие се отказвате от много от предимствата на RDBMS.
Postgis
Предвид проблемите, които имахме с MySQL, в крайна сметка преобразувахме в Postgis. Ключовите моменти от това преживяване бяха.
1). Изключителна стабилност. Няма повреда на данните за 5 години и вече имаме около 25 Postgres/GIS кутии на виртуални машини centos, при различна степен на натоварване.
2). Бързи темпове на развитие – растер, топология, поддръжка на 3D са скорошни примери за това.
3). Много активна общност. Irc каналът на Postgis и пощенският списък са отлични ресурси. Референтното ръководство на Postgis също е отлично. http://postgis.net/docs/manual-2.0/
4). Играе много добре с други приложения, под шапката на OSGeo, като GeoServer и GDAL.
5). Съхранените процедури могат да бъдат написани на много езици, с изключение на plpgsql по подразбиране, като Python или R.
5). Postgres е напълно съвместима със стандартите, пълнофункционална RDBMS, която има за цел да остане близо до стандартите ANSI.
6). Поддръжка за функции на прозорци и рекурсивни заявки - не в MySQL, а в SQL Server. Това направи писането на по-сложни пространствени заявки по-чисто.
SQL сървър.
Използвах само пространствена функционалност на SQL Server 2008 и много от неприятностите на тази версия – липса на поддръжка за преобразувания от една CRS в друга, необходимостта да добавяте свои собствени параметри към пространствените индекси – вече са разрешени.
1). Тъй като пространствените обекти в SQL Server са основно CLR обекти, синтаксисът се усеща обратно. Вместо ST_Area(geom) вие пишете geom.STArea() и това става още по-очевидно, когато свържете функциите заедно. Отпадането на долната черта в имената на функциите е просто незначително досада.
2). Имах редица невалидни полигони, които бяха приети от SQL Server и липсата на функция ST_MakeValid може да направи това малко болезнено.
3). Само за Windows. Като цяло продуктите на Microsoft (като тези на ESRI) са проектирани да работят много добре един с друг, но не винаги имат съответствие със стандарта и оперативна съвместимост като основни цели. Ако използвате магазин само за прозорци, това не е проблем.
АКТУАЛИЗИРАНЕ :след като поиграх малко с SQL Server 2012, мога да кажа, че е подобрен значително. Вече има добра функция за валидиране на геометрията, има добра поддръжка за типа данни Geography, включително обект FULL GLOBE, който позволява представяне на обекти, които заемат повече от едно полукълбо и поддръжка за сложни криви и кръгови низове, което е полезно за точни и компактни представяне на дъги (и окръжности), наред с други неща. Трансформирането на координати от една CRS в друга все още трябва да се извършва в библиотеки на трети страни, въпреки че това не е запушалка в повечето приложения.
Не съм използвал SQL Server с достатъчно големи набори от данни, за да сравнявам един по един с Postgis/MySQL, но от това, което видях, функциите се държат правилно и макар да не са толкова пълнофункционални като Postgis, това е огромно подобрение на предложенията на MySQL .
Съжалявам за толкова дългия отговор, надявам се част от болката и радостта, които изпитвах през годините, може да са от полза на някого.
