Моделирование схемы приглашения со встроенными коллекциями с dynamodb или documentemntdb

Question

Я изучаю, использовать ли AWS DynamoDb или Azure DocumentDb или облако Google для цены и простоты для моего приложения, и мне интересно, какой лучший подход подходит для типичной схемы приглашения.

инвайт имеет

• USERID: ключ (который создал приглашение)
• GameID: ключ
• invitationList: коллекция UserIds

Запросы я бы бег

1. Получить приглашения, где userId == я
2. Get приглашает где мой идент в invitationList

В Монго, я бы просто установить индекс на встроенном invitationList, и в SQL я бы создал присоединиться таблицу GameID и пригласил UserIds ,

Использование dynamodb или documentdb, могу ли я сделать это в одной «таблице», или мне нужно будет создать вторую денормализованную таблицу, в которой есть приглашенный пользовательский указатель на строку с набором приглашенныхGameIds?

например.

Вторичный стол с

• InvitedUserId: ключевые
• GameIds: Коллекция

Answer 1

Как и в случае с ответом hslriksen, если определенные критерии выполнены, я рекомендую денормализовать все это в один документ. Этими критериями являются:

1. Список приглашений для игр не может расти неограниченно.
2. Даже если он ограничен, будет ли массив максимальной длины соответствовать документу и границам транзакций.

Однако, в отличие от hslriksen я рекомендую пример документ выглядит следующим образом:

{ 
    gameId: <some game key>, 
    userId: <some user id>, 
    invitationList: [<user id 1>, <user id 2>, ...] 
} 

Вы также можете решить, использовать встроенный в id поле для игры в этом случае имя выше неправильно.

Ключевое различие между тем, что я предлагаю и hslriksen, заключается в том, что приглашениеList представляет собой чистый массив внешних ключей. Это позволит использовать индексы для предложения ARRAY_CONTAINS в вашем запросе.

Обратите внимание, что в DocumentDB вы хотели бы хранить все типы сущностей в одном большом ведре и просто отличать их от строки type или немного лучше, с булевым полем is_my_type.

Answer 2

Для DocumentDB вы могли бы, вероятно, просто держать это в одном документе за приглашения пользователю где документ Id может равняться ключ приглашающего пользователя. Если у вас много игр, вы можете использовать gameId как partitionKey.

{ 
    "id" : "gameKey+invitingUserKey", 
    "gameKey" : "someGameKey", 
    "invitingUserId": "key", 
    "invites": ["inviteKey1", "inviteKey2"] 
} 

Это на основе ограниченного количества приглашений для пользователя/игры. Однако сложно определить структуру, не зная ваши шаблоны запросов. Я считаю, что шаблоны запросов часто диктуют структуру документа.