Отношения "многие ко многим" с базой данных NoSQL

Я хочу реализовать структуру таксономии (гео-термины) для моего узла.приложение js с базой данных NoSQL. У меня была аналогичная структура таксономии с MySQL, но пришло время двигаться вперед и узнать что-то новое, поэтому я решил попробовать другой подход и использовать NoSQL (ориентированный на документ) для моего тестового приложения. Структура таксономии проста - есть пять различных уровней: страна (то есть Великобритания) → регион (Англия) → графство (Мерсисайд) → город/городок / деревня (Ливерпуль) → часть города (Toxteth).

очевидный выбор-использовать древовидную структуру, но дьявол в деталях-исторически некоторые города и поселки принадлежали другим графствам. Идея заключалась в том, чтобы пометить людей, которые родились в определенных городах или поселках, этими терминами и фильтровать их позже по тегам geo, поэтому я должен уважать тот факт, что Ливерпуль или Манчестер (среди прочих) были частью Ланкашира в то время, когда некоторые люди родились. В противном случае результат, который получит любой пользователь с моим Geo-фильтром, будет неправильный.

пример: Джон Доу родился в Блэкберне (Ланкашир) еще в 1957 году. Пол Браун родился в 1960 году в Ливерпуле (Ланкашир, ныне Мерсисайд). Джорджия Доу (урожденная Джонс) родилась в Виррале (Чешир, ныне Мерсисайд) 5 лет спустя. Их сын Ринго родился в Ливерпуле (Мерсисайд к тому времени) в 1982 году.

Джон Ланкастер по рождению, пол Ланкастер и Мерсисидер, Джорджия из Чешира и Мерсисайда в то же время, Ринго из Мерсисайд. Поэтому их следует классифицировать соответствующим образом, когда я ищу по округам. Но с простой структурой "один ко многим", которая следует за современной структурой страны, они никогда не будут отфильтрованы так, как должны быть.

как реализовать коллекцию с учетом сложности ее структуры с помощью решений NoSQL (прежде всего, ориентированных на документы)? Я погуглил его и сделал некоторые исследования над стеком*, но все еще не знал, что с ним делать дальше. Есть несколько возможных способов решить это в моем мнение:

1. используйте SQL-подобную структуру данных:

   {
       {'name': 'United Kingdom', 'unique_id': 1},
       {'name': 'England', 'unique_id': 2, 'parents': [1]},
       {'name': 'Merseyside', 'unique_id': 3, 'parents': [2]},
       {'name': 'Lancashire', 'unique_id': 4, 'parents': [2]},
       {'name': 'Liverpool', 'unique_id': 5, 'parents': [3, 4]},
   }
   

2. использовать древовидную структуру с некоторыми ссылками:

   {    
       {'name': 'United Kingdom', 'unique_id': 1
           {'name': 'England', 'unique_id': 2]
               {'name': 'Merseyside', 'unique_id': 3]
                   {'name': 'Liverpool', 'unique_id': 5, 'alternate_parents': [4]},
               },
               {'name': 'Lancashire', 'unique_id': 4},
           },
       },
   }
   

3. используйте древовидную структуру без ссылок (один ко многим) и добавьте тег" альтернативный родитель " в документ вручную:

   {    
       {'name': 'United Kingdom', 'unique_id': 1
           {'name': 'England', 'unique_id': 2]
               {'name': 'Merseyside', 'unique_id': 3]
                   {'name': 'Liverpool', 'unique_id': 5},
               },
               {'name': 'Lancashire', 'unique_id': 4},
           },
       },
   }
   

4. придерживайтесь SQL.

5. попробуйте реализовать без базы данных таксономии.

Дайте мне совет по этому поводу вопрос пожалуйста. Я новичок с любым NoSQL (в настоящее время я не разрабатывал такие базы данных), поэтому для меня есть реальная проблема дизайна.

и я новичок в стеке* так что не стесняйтесь поправлять меня, если я сделал что-то не так с этим сообщением :) спасибо!

редактировать Я выбрал @Jonathan answer в качестве решения. Я думаю, что это лучше подходит для моих нужд (в моей базе данных будут храниться другие документы и помечать их этими терминами), особенно с функциональностью mapReduce предложено @Valentyn.

но если для вашего приложения нет коллекций документов, то графическая база данных (основанная на отношениях, а не на документах), предложенная @Philipp, вероятно, является лучшим решением.