Возможные варианты хранения иерархических данных

Question

Нам нужна возможность сопоставлять различные типы объектов с различными типами иерархических данных в нашем веб-приложении. В качестве примера рассмотрим объект под названием Vendor. Нам нужна возможность сопоставлять каждый экземпляр поставщика с географическими регионами. Географические области находятся в следующей иерархии:

1. Почтовый индекс - наиболее гранулированный географический район; пример EC2
2. Местность - сформирован из почтовых индексов; пример, Кенсингтон. Каждый почтовый код будет частью только одного местоположения, не более того.
3. Город - образованный населенных пунктов; например, Лондон. Каждое местонахождение будет частью ровно одного города, не более.
4. Район - образованный из городов; Например, Колумбия.
5. Провинция - образована из районов (что эквивалентно государству в некоторых странах); например, Южная Каролина.
6. Регион - образованный провинций; Например, северо-восточные провинции.
7. Страна - сформирована из регионов.
8. Зона - из стран; пример Юго-Восточной Азии.
9. Континент - сформирован из зон.

У нас есть полная база данных почтовых индексов, населенных пунктов, городов, районов, провинций, регионов, стран, зон и континентов. Это в настоящее время существует как таблицы в СУБД.

Наших случаи использования:

1. Возможность ассоциировать Vendor с несколькими регионами, на любом уровне. Например, мы могли бы сопоставить Nestle в материковой Европе (зона), Калифорнии (провинция США) и Большого Лондона (район в Великобритании).
2. Возможность исключить некоторые части географии из картографирования. Например, при картировании Nestle до California, мы можем исключить San Diego.
3. Если состав географии изменяется, не требуется никаких изменений для сопоставлений, частью которых является география. Например, если почтовый код добавлен в Greater London, отображение с Nestle не требует изменений.
4. Возможность запроса базы данных для Поставщик и уровень географии. Например, если мы делаем запрос к базе данных для Nestle и почтовых кодов, мы должны получить все почтовые коды для Большого Лондона, Калифорния (минус почтовые индексы для Сан-Диего) и материковой Европы.Если запрос к базе данных для Nestle и стран, мы должны получить Великобритании (страна для Большого Лондона), США и во всех странах материковой Европы.

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

Ищет предложения по хранению иерархических данных и сопоставлений. Пожалуйста, не публикуйте ответы, которые связаны с хранением данных и сопоставлений в таблицах РСУБД, поскольку я уже знаю о вариантах с использованием РСУБД.

Answer 1

Я знаю, что вы не ищете решение для РСУБД, так как вы «знаете варианты для РСУБД» - но вы не указываете, какие варианты вы рассмотрели и почему вы их отвергаете. Я считаю, что может быть вариант RDBMS, который вы не учли, что имеет преимущество низкого обслуживания данных и простоты извлечения данных.

Предлагаю вам объединить географические регионы в единую таблицу с инволюцией (adjacency model). Это позволяет описать охват вашего поставщика как список записей географического охвата. Хитрость заключается в том, чтобы зафиксировать охват поставщиков на максимально возможном уровне. Затем вы можете также перечислить исключения для покрытия.

Вот предложил логическая модель:

В таблице GEOGRAPHY можно использовать nested sets упростить обработку запросов иерархических данных по географии.

Определение покрытия поставщика конкретной области будет столь же легко, как подтверждение того, что продавец имеет COVERAGE для GEOGRAPHY интереса (вероятно, на самом низком уровне), а также не быть в COVERAGE EXCLUSION для того же GEOGRAPHY.