Для представления отношения «многие ко многим» в DB «Динамо» я обычно видел два подхода: глобальный вторичный индекс (GSI) и список смежности. Теперь мой вопрос, когда использовать какой?
Использование GSI в основном состоит в том, чтобы перевернуть ключ разделения и отсортировать ключ, чтобы данные можно было эффективно запрашивать в обоих случаях. Примеры показывают что-то вроде онлайн-игры с игроками, например
Players table
--------------
Partition | Sort
-----------------
Player 1 | Game 1
Player 1 | Game 2
Player 2 | Game 1
Player 3 | Game 2
Games GSI
-----------
Partition | Sort
-----------------
Game 1 | Player 2
Game 1 | Player 2
Game 2 | Player 1
Game 2 | Player 3
Я делаю предположение, что это все сеансы на одной игровой платформе, то есть совпадают с конечным количеством игроков.
Все это кажется простым и логичным для реализации ... Пока данные не станут немного сложнее. Что если и у Игроков, и у Игр свой набор атрибутов? Допустим, у игры есть атрибут, когда она была запущена, а у игрока есть такие атрибуты, как имя пользователя и личный счет игры. Как они проецируются на каждую таблицу и GSI?
Например, требуемые проекции будут выглядеть примерно так
Получить игроков, участвующих в игре
// query made with game id
{
start_date: '2018-11-04T13:00Z',
status: 'IN_PROGRESS',
players: [
{
username: 'starkshark',
points: 200
},
{
username: 'coldshot',
points 300
}
]
}
Получить игры, в которых участвовал игрок
// query made with player id
{
username: 'starkshark',
games: [
{
status: 'IN_PROGRESS',
start_date: '....'
},
{
status: 'ENDED',
start_date: '...',
end_date: '...'
}
]
}
Или это пограничный случай, когда нужно использовать шаблон списка смежности? Из того, что я прочитал в целом о списках смежности, довольно сложно реализовать простое отношение «многие ко многим», как в приведенном выше примере с онлайн-играми. Что я понял, это предназначено для моделирования графиков с несколькими узлами, связанными друг с другом. Конечно, в этом случае узлами будут Игры и Игроки (и, возможно, любая другая сущность, необходимая в модели)
TLDR : Таким образом, все сводится к последним вопросам, при наличии отношения «многие ко многим» между объектами, имеющими свой собственный набор атрибутов, список соседей - опция для поиска или Есть ли менее сложная структура данных для модели?