DynamoDB - Ассоциативная таблица - отношение «многие ко многим» - PullRequest
Новая
       12

DynamoDB - Ассоциативная таблица - отношение «многие ко многим»

0 голосов
/ 01 сентября 2018

У меня есть сценарий в DynamoDb, где записи имеют отношение «многие ко многим».

Обычно в SQL я создаю ассоциативную таблицу, чтобы разделить записи на отношения «один ко многим».

Например:

  1. Истории могут иметь несколько мест
  2. Места имеют несколько историй

Вот пример записи: 

{
  "storyId": "asd239ruefjsp32wf",
  "name": "Donut store",
  "locations": [
    {
      "locationId": "asdas23r23",
      "name": "New South Whales",
      "abbreviation": "NSW"
    },
    {
      "locationId": "sdgkhsdf98",
      "name": "Queensland",
      "abbreviation": "QLD"
    }
  ]
}

Возможно, это можно разделить на 3 таблицы:

Рассказы

  • storyId
  • 1025 * Места *

Местоположение

  • locationId

StoriesLocations (с GSI - partitionKey = locationId)

  • storyLocationId
  • storyId
  • locationId

Моя большая проблема в том, что пользователь может искать истории, используя более 1 locationId. 

GET /stories?locations=sdgkhsdf98,asdas23r23

Запрос GSI для StoriesLocations с использованием каждого storyId по отдельности не кажется хорошим решением, особенно если мне тогда придется получить все данные истории после слов и управлять разбиением на страницы.

В настоящее время существует только 1 страна с 7 местоположениями. Таким образом, только несколько мест будут обыскиваться.

Есть ли более эффективный способ хранения данных? или даже спрашивая?

Я выбрал DynamoDB из-за его скорости, и обычно я занимаюсь разработкой интерфейса. Так что с настройкой базы данных SQL у меня не было большого опыта. Я также буду использовать чата в реальном времени Appsync, который по умолчанию использует DynamoDB.

1 Ответ

0 голосов
/ 01 сентября 2018

я думаю только 1 таблица и 1 локальный вторичный индекс (LSI) т.е. Истории и местоположения в качестве локального вторичного индекса (LSI) таблицы историй необходимы в вашем сценарии. Таблица Stories использует storyId в качестве Hash/partition Key и местоположения в качестве Sort/range Key. Что касается LSI, вы можете использовать местоположения в качестве ключа сортировки и проецировать любые атрибуты таблицы Stories, которые вам нужны, в LSI, поскольку вы можете запросить их позже. это больше информации о DyamoDB LSI и ключе сортировки

Подробнее смотрите здесь . 

Stories
HK storyId
SK locations
name
...


(LSI) storiesLocationsIndex
SK locations
name
...

Надеюсь, это поможет

...