Это во многом зависит от того, какие запросы вам нужно поддерживать для ваших данных, и вам следует подумать о них более тщательно в модели NoSQL, чем в реляционной модели.
Лично явероятно, начнем с двух таблиц, для групп и пользователей, каждая из которых имеет ключи appId (PK) и groupId / userId (SK), с другими свойствами для деталей.Тогда в таблице users у меня будет поле userGroups в виде StringSet, содержащее список идентификаторов групп, в которых находится пользователь. Это дает вам возможность запрашивать:
- Все пользователи в данном приложении
- Все группы в данном приложении
- Все группы для данного пользователя в данном приложении (следовательно, находится ли данный пользователь в определенной группе)
При выполнениипоследний запрос (все пользователи для данной группы в данном приложении) является редким случаем (или количество пользователей в приложении невелико), вы можете выполнить операцию сканирования таблицы пользователей с ключом appId и фильтрации в группах пользователейполе.Если производительность этого запроса более важна, но количество пользователей в группе не слишком велико, вы можете иметь поле зеркала groupUsers StringSet в таблице групп в качестве зеркала и поддерживать синхронизацию двух полей либо на уровне приложения.или путем репликации из одного в другой с помощью DynamoDb Streams.
Или вы можете выделить отображение в отдельную таблицу, почти так же, как в реляционной базе данных.Вы должны задать эту таблицу с помощью appId (PK) userId (SK), а затем создать глобальный вторичный индекс для appId (PK) groupId (SK), чтобы разрешить запросы в другом направлении.AWS будет обновлять индекс при любых изменениях данных.