Я работал со всеми тремя базами данных и делал миграции между ними, поэтому, надеюсь, я все же могу добавить что-то в старое сообщение. Десять лет назад мне было поручено разместить довольно большие 450 миллионов пространственных объектов - набор данных из GML в пространственную базу данных. Я решил опробовать MySQL и Postgis, в то время, когда в SQL Server не было пространств, и у нас была небольшая атмосфера запуска, поэтому MySQL казался подходящим. Впоследствии я был вовлечен в MySQL, я присутствовал/выступал на нескольких конференциях и активно участвовал в бета-тестировании более совместимых с ГИС функций в 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. Мой опыт перехода к конференциям состоял в том, что пространственное звучание было очень запоздалым - мы реализовали репликацию, разбиение на разделы и т. Д., Но это не работает с пространственным. EDIT: В upcoming 5.7.5 release InnoDB, наконец, будет поддерживать индексы в пространственных столбцах, что означает, что ACID, внешние ключи и пространственные индексы будут, наконец, доступны в одном и том же движке.
3). Пространственная функциональность чрезвычайно ограничена по сравнению с пространством Postgis и SQL Server. Там до сих пор нет функции 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 Oracle пространственная система действительно была приостановлена.
В целом, если быть честным с MySQL, он поддерживал наш веб-сайт, WMS и общую пространственную обработку в течение нескольких лет, и его было легко настроить. С другой стороны, повреждение данных было проблемой, и, будучи вынужденным использовать таблицы MyISAM, вы отказываетесь от многих преимуществ РСУБД.
PostGIS
Учитывая вопросы, которые мы имели с MySQL, мы в конечном счете превращается в PostGIS. Ключевыми моментами этого опыта были.
1). Крайняя стабильность. Нет повреждения данных за 5 лет, и теперь у нас есть около 25 полей Postgres/GIS на виртуальных машинах centos при различной степени нагрузки.
2). Быстрые темпы развития - растровая, топологическая, трехмерная поддержка - недавние примеры этого.
3). Очень активное сообщество. Канал Postgis irc и список рассылки - отличные ресурсы. Справочное руководство 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 Server.
Я использовал пространственную функциональность 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, могу сказать, что он значительно улучшился. В настоящее время существует хорошая функция проверки геометрии, существует хорошая поддержка типа данных географии, включая объект FULL GLOBE, который позволяет представлять объекты, которые занимают более одного полушария и поддерживают Compound Curves and Circular Strings, что полезно для точных и компактных представлений дуг (и круги) между прочим. Преобразование координат из одной CRS в другую все еще должно быть сделано в сторонних библиотеках, хотя это не является пробной пробкой в большинстве приложений.
Я не использовал SQL Server с достаточно большими наборами данных для сравнения один на один с Postgis/MySQL, но из того, что я видел, функции функционируют корректно, и хотя они не так полно, как Postgis, это огромный улучшение предложений MySQL.
Извините за такой длинный ответ, я надеюсь, что некоторые из страданий и радости, которые я испытал на протяжении многих лет, могут кому-то помочь.
PostGIS будет наиболее зрелым из вариантов. –
PostGIS на сегодняшний день является самым зрелым решением для ГИС. И если вы используете R, вы даже можете использовать PL/R для записи хранимых процедур в R. Пространственные расширения MySQL довольно тонкие, и имхо не стоит пытаться, возможности GIS SQL Server довольно новы и кажутся несколько ограниченными, но у меня есть никакого опыта с этим пока нет. – Wolph
Отличный и важный вопрос. Мнения, основанные на фактах, ценны. Не должно быть закрыто. – ErichBSchulz