База данных документов - Моделирование данных с использованием вложенных данных (CosmosDB, Mongo и т. Д.) - PullRequest
Новая
       34

База данных документов - Моделирование данных с использованием вложенных данных (CosmosDB, Mongo и т. Д.)

0 голосов
/ 14 октября 2018

У нас есть данные о местонахождении клиентов в нашей RDMBS, и мы исследуем нашу архитектуру vNext, которая может быть преобразована в архитектуру Document DB (Json).Буду признателен за любые предложения / ссылки / Youtubes / и т. Д., Чтобы помочь с вложенными местоположениями.

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

В настоящее время мы храним их примерно так (pseudo mssql dml): 

create table Location as 
   LocationID int identity(1,1),
   LocationName varchar(250),
   (other fields)
   ParentLocationID int

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

Кроме того, наши приложения могут ограничивать доступ пользователей с помощью набора разрешений.

Пользователь A может получить доступ ко всем местоположениям. Пользователь B может получить доступ только к местоположениям 5, 6, 7, 8, 9, 10

Эти разрешения применяются к большинству поисков.В настоящее время мы просто храним их в реляционных таблицах ---> User & UserLocation.

Это будет "чистый" встроенный подход, но я не думаю, что он обязательно будет лучшим выбором.Поскольку каждая БД, кажется, имеет идентификатор, который является либо назначаемым пользователем, либо автоматически созданным значением, я исключил его из модели.

{
    "name": "North America",
    "locations": [
    {    
        "name": "Canada",
        "locations": [
        {
            "name": "Alberta",
            "locations": [
            {
                "name": "Banff",
                "locations": [
                {                  
                    "name": "Main Street",
                    "locations": [ ]
                 },
                 ]               
           },
           ]   
       },
       ]   
   },
   ]   
}

Мои первые мысли состоят в том, чтобы пойти с гибридным подходом - где местоположение хранит только идентификатор его подклассов

{"id": "NA", "name": "Северная Америка "," location ": [" CA "," US "]},

{" id ":" CA "," name ":" Canada "," location ": [" AB ", "BC", ...]},

{"id": "AB", "name": "Alberta", "location": ["Banff", "Calgary", ...]},

{"id": "Banff", "name": "Banff", "location": ["Main Street", ...]}

Идентификаторы будутдолжен быть либо GUID, либо каким-либо другим уникальным значением;вышеуказанные значения только для демонстрационных целей.В отдельных документах ресурсы будут ссылаться на идентификатор.У каждого клиента хранятся разные значения, но соотношение ресурсов: местоположение может варьироваться от 10: 1 до 10 000: 1. 

{
    "name": "laptop",
    "type": "computer",
    "location": "Building1" 
}

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

Спасибо

...