Смешивание типов геометрии в одной таблице PostGIS

Я столкнулся со следующей проблемой. Я должен перейти с базы данных Oracle на PostgreSQL + PostGIS. В настоящее время все геометрии всех типов хранятся в одной таблице, и каждая запись содержит поле «крышка», которое указывает особенности одного и того же слоя.

Каковы плюсы и минусы использования такого метода? Стоит ли разбивать данные на несколько таблиц, если мне не нужно использовать базу данных со сторонним программным обеспечением? Как насчет производительности пространственных запросов, помогут ли мне индексы?

Если вам не нужна сторонняя поддержка и вы не видите необходимости в запросе по типу, сохраняя их в одной и той же таблице, все будет в порядке. В качестве альтернативы вы можете использовать модель наследования, как описано в главе 3 PostGIS in Action.

http://www.postgis.us/chapter_03_edition_1

С точки зрения архитектуры PostGIS на самом деле не волнует, используется ли в запросе несколько разных типов. Если в Oracle все работает нормально, то в PostGIS это будет не лучше.

Есть две причины, чтобы разделить его (и любой из них можно сделать позже по мере необходимости): 1) Запретить людям вставлять разные типы, которые вам не нужны, например, коллекции геометрии, круглые строки, а что нет (что вы можете просто определить ограничение вручную. )

2) Если у вас есть миллиард точек и 1000 полигонов, и вы много тестируете в тестах полигонов, скорость будет намного выше, если вы запрашиваете и выполняете объединение - против таблицы записей от миллиарда до 1000, а не таблица рекордов от миллиарда до миллиарда. Я думаю, это относится к любой пространственной базе данных (не относится только к PostGIS). Это верно для всех реляционных запросов, я бы тоже догадался (не только для пространственных запросов).

Этот действительно беспокоит меня. Я думаю, это потому, что я видел слишком много файлов САПР с данными на одном слое, различающихся только по цвету.

На самом деле все сводится к выбору организации данных по структуре или по атрибутам .

Если бы у меня был такой выбор, я бы всегда организовывал свои данные через структуру данных.

Для начала, при обработке данных у вас есть на один обруч меньше, например, для выбора a, b, c из таблицы, где id = X, в отличие от выбора a, b, c из таблицы, где id = X AND lid = Y )

Затем подумайте, почему базы данных допускают использование нескольких таблиц - если формат данных предлагает конкретные структуры данных, вы должны подумать, что они будут обрабатывать данные более эффективно, если вы их используете.

Но большая проблема (для меня) - это когда вы хотите переместить данные в другую систему. Тогда я думаю, что это становится реальной проблемой, потому что конечное приложение может не использовать данные таким же образом. Я видел, как многие люди отклеились от этого сценария.

Так что - по моему опыту - вы сможете использовать и передавать данные вдвое эффективнее, если у них есть достойная (более глубокая и более структурированная) модель данных.