PostGIS против SQL Server для данных ГИС

15

Так что я недавно начал работать в новой компании, и у меня появилось много пользователей ArcGIS, которые, похоже, действительно заинтересованы в продвижении вперед с экземпляром PostGIS для предоставления некоторых данных нашим клиентам. Хотя у меня нет проблем с этим, мы на 95% SQL Server и на 5% Oracle. Наша текущая внутренняя ГИС работает на SQL Server, и мне еще не приходилось слышать никаких жалоб.

Я знаю, что SQL Server имеет множество улучшенных пространственных и геометрических возможностей с 2012 года, но есть ли в PostGIS какие-нибудь убийственные функции, для которых стоит взломать новую платформу? Я пытался исследовать это, но не могу найти что-то действительно глубокое, или это не совсем предвзято.

Я хочу дать им лучшие инструменты для выполнения своей работы, но также должен взвесить тот факт, что я буду изучать Postgres / GIS с самого начала, и это целый путь сам по себе.

LowlyDBA
источник
1
Если вы передаете данные клиентам из него с помощью ArcGIS For Server, то единственным соображением будет производительность. Несмотря на то, что он обладает более широким диапазоном пространственной функциональности, я не думаю, что что-либо из этого будет убойной или, вероятно, потребуется ArcGIS. К сожалению, у меня нет тестов производительности.
MickyT
Вековая мантра использования того, что вы знаете, безусловно, применима и здесь. Переход на другую платформу всегда кажется хорошей идеей, прежде чем приступать к изменениям. Не так много позже, когда вы через 6 месяцев осознаете, что только начали получать необходимые знания. Вы когда-нибудь слышали о стоимости альтернатив?
Макс Вернон,
2
Нет опыта работы с продуктами ARC, но когда речь идет только о базах данных. PostGIS - это более зрелая реализация пространственной базы данных, чем сервер MSSQL, больше примеров, больше бесплатного контента. Если вам нужно сделать что-то пространственное в БД, PostGIS имеет больше опций. PostGIS бесплатен, MS SQL - нет, пространственные базы данных имеют тенденцию к росту больше, чем ожидалось. Поэтому возникают проблемы с лицензированием и т. Д. Конечно, у Linux + PostGIS есть свои проблемы, если администраторы более привыкли к среде Windows.
симплексио

Ответы:

21

Я работал как с Postgres, так и с SQL Server. Я обнаружил, что Postgres превосходит ГИС по функциональности. И хотя я собираюсь кратко изложить свои выводы ниже, я бы предложил следующее: Дайте себе короткий, но разумный период времени, чтобы рассмотреть незнакомое решение по сравнению с тем, которое вы знаете, с учетом конкретных целей. Например, возможно, 2-недельный период времени для установки и изучения некоторых конкретных функций, которые используются в настоящее время. Если вы обнаружите, что застряли или у вас нет функциональности в течение этого периода времени, то вы знаете, что это не для вас. Это инвестиция в исследования, которая расширяет ваши взгляды и помогает вам понять, что вы, возможно, упустили что-то, о чем вы раньше не знали, или просто подтвердите, что ваш текущий курс - прямо сейчас.

Что касается базы данных, я обнаружил, что Postgres имеет более короткую и более мелкую кривую обучения. Документация просто невероятная. В SQL Server есть довольно много документации, но я нахожу ее трудной для чтения, с недостаточным количеством примеров и руководств.

PostGIS и SQL Server Spatial аналогичны приведенным выше в отношении документации, но PostGIS превосходит функциональность SQL Server Spatial. Например, Google Maps и, в меньшей степени, Bing Maps недавно добавили полную поддержку geoJSON в API своих карт. Итак, PostGIS может легко вернуть результат geoJSON непосредственно из запроса к базе данных, используя ST_AsGeoJSON () . Этот результат geoJSON может быть затем передан непосредственно любому, кто может понять geoJSON. SQL Server требует от вас использования дополнительной библиотеки и обработки или использования ogr2ogr. Кроме того, PostGIS имеет более 300 функций, доступных для преобразования данных в базу данных и из нее, по сравнению с SQL Server, который имеет около 70-100.

TechJohn
источник
Как только вам понадобятся полигоны, используйте PostGIS - вы избавите себя от многих проблем. Если вам нужны только точки, может быть, SQL-Server достаточно, но тогда вы можете просто использовать два десятичных столбца (2 столбца не рекомендуется, если вам нужно делать расчеты расстояния - используйте GeoPoint). GeoPoint не рекомендуется, если вы используете EntityFramwork / LINQ2SQL / AverageCrappyORM.
затруднительное
0

Мне кажется, что то, какой БД лучше, здесь не является вашей главной задачей, и вместо этого у вас есть два разных соображения, которые касаются друг друга, а именно: знание бизнеса против желания клиента. В конечном итоге это будет бизнес-решение, а не техническое решение.

Очевидно, что есть альтернативная стоимость, как Макс отметил в комментарии. Обойти это невозможно. Если вы едете по маршруту Postgres, пожалуйста, подумайте о том, чтобы получить некоторую помощь в виде хорошего консалтингового соглашения, опытного dba или обоих.

Если ваши пользователи хотят PostGIS, это может быть чистой победой. Сколько еще ваших услуг вы продадите, совершив переход? Будет ли оно того стоить по возможности? Это не решения, которые будут приниматься на основе того, какой дБ лучше в ваших глазах или с точки зрения технических характеристик, а с точки зрения кривой обучения и маркетинга.

Крис Траверс
источник
Отличное понимание выбора под рукой - спасибо Крис.
LowlyDBA
Какой БД лучше, здесь главное. SQL-сервер не может обрабатывать данные такого размера (planet.osm). Кроме того, он пропускает множество функций, которые вам действительно нужны, если вы собираетесь делать больше, чем академические исследования (векторные тайлы, геойсон и т. Д.). Кроме того, он не может обрабатывать полигоны, проходящие с одной стороны экватора на другую (глупо), что вызывает беспокойство, если вам нужны Бразилия, Эквадор, Колумбия, др., Габон, Кения, Сомали, Малайзия, Индонезия, Сингапур, Папуа или Индийский, Тихий или Атлантический океан и т.д. Кроме того , ошибки , если многоугольник имеет неправильное направление - вместо автоматических обращенного ...
затруднительный