Змішування типів геометрії в одній таблиці PostGIS

Я зіткнувся з наступною проблемою. Мені потрібно перейти з бази даних Oracle до PostgreSQL + PostGIS. В даний час всі геометрії всіх типів зберігаються в одній таблиці, і кожен запис містить поле "кришка", яке вказує на особливості одного шару.

Які плюси та мінуси використання такого методу? Чи слід розбивати дані на кілька таблиць, якщо мені не потрібно використовувати базу даних із стороннім програмним забезпеченням? Що щодо виконання просторових запитів, чи допоможуть мені індекси?

Якщо вам не потрібна підтримка сторонньої сторони і не забуваєте про необхідність запиту за типом, зберігання їх у одній таблиці працює чудово. Ви також можете використати модель успадкування, про яку йдеться у розділі 3 PostGIS в дії.

http://www.postgis.us/chapter_03_edition_1

З точки зору архітектури PostGIS не дуже важливо, якщо в запиті використовується кілька різних типів. Якщо це буде добре для вас в Oracle, це буде так само, як ніби не кращим виконавцем в PostGIS.

Є дві причини розділити це (і це можна зробити пізніше за необхідності): 1) Не дозволяйте людям вставляти різні типи, які вам не подобаються, як колекції геометрії, кругові рядки і що ні (що ви могли вручну визначити обмеженням )

2) Якщо у вас мільярд очок і 1000 багатокутників, і ви багато вказуєте на тести на багатокутники, швидкість набагато краще, якщо ви запитуєте і приєднуєтесь - її проти мільярда - до 1000 записів таблиці на відміну від рекордна таблиця на мільярд до мільярдів. Це стосується будь-якої просторової бази даних, на яку я думаю (не специфічна для PostGIS). Це правда для всіх реляційних запитів, я б також здогадався (не характерно для просторових запитів).

Цей мене справді турбує. Я думаю, це тому, що я бачив занадто багато CAD-файлів із даними, які є на одному шарі, диференційовані лише за кольором.

Що зводиться до нас, це насправді вибір між організацією даних за структурою або за атрибутом .

Враховуючи такий вибір, я б завжди намагався організувати свої дані через структуру даних.

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

Потім подумайте, чому бази даних дозволяють використовувати декілька таблиць - якщо формат даних пропонує певні структури даних, ви повинні думати, що вони оброблять дані більш ефективно, якщо ви їх використовуєте.

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

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