#mongodb #realm #realm-mobile-platform
#mongodb #область #область-мобильная платформа
Вопрос:
Я работаю над разделением данных MongoDB Atlas на области, чтобы использовать функцию синхронизации областей для мобильных устройств. Для справки я смотрю на информацию, представленную здесь:
https://docs.mongodb.com/realm/sync/partitioning/#partitioning
При совместном использовании данных между пользователями MongoDB предлагает следующую стратегию разделения:
Области пользователей: Если ваше приложение хранит данные конфиденциально для каждого отдельного пользователя, вы могли бы создать поле owner_id, содержащее определенный идентификатор пользователя для каждого документа. Выбор поля owner_id в качестве ключа раздела приведет к разделению вашей базы данных на области, соответствующие отдельным пользователям.
Области команд: Если ваше приложение использует ресурсы совместно с командами, вы могли бы создать коллекцию команд, которая сопоставляет идентификаторы пользователей с идентификаторами команд. Затем вы могли бы создать поле team_id, содержащее определенный идентификатор команды для каждого документа, который вы хотите синхронизировать. Выбор поля team_id в качестве ключа раздела приведет к разделению вашей базы данных на области, содержащие данные для целых команд.
Общедоступные области: Часто бывает полезно хранить данные только для чтения, доступные для просмотра всем пользователям; для такого варианта использования вы можете определить специальное значение раздела в своих разрешениях, например PUBLIC, которое все пользователи синхронизируют только с разрешениями на чтение.
Итак, все это имеет смысл, но как насчет документов, которые пользователь создает, а затем предоставляет доступ к одному или нескольким другим пользователям? Если у меня есть sharedWith
поле, которое указывает на другое user_id's
, и я делаю это ключом раздела, тогда это может сработать, но вся документация, похоже, предостерегает от обновления значения этих ключей раздела из-за риска запуска сброса клиента.
Благодаря исследованию, которое я провел через Google, StackOverflow и т.д., Я могу найти только примеры, в которых предполагается, что данные остаются статичными, но мне нужно разрешить пользователям добавлять и удалять разрешения на общий доступ. Есть предложения о том, как к этому можно подойти?
Комментарии:
1. Если вы делитесь объектом с другими, это будет считаться «командой», чтобы стратегия работала. Если они открыты для всех остальных, то они будут считаться общедоступными. Если вы разрешаете другим пользователям доступ к вашей области, это будет пользователь, но у других будут права доступа. Итак, как вы можете видеть, без понимания всего варианта использования было бы очень сложно дать конкретный ответ.
2. Спасибо, Джей. Вариант использования заключается в том, что пользователи могут случайным образом предоставлять доступ к своим документам одному или нескольким другим пользователям. Общий доступ не привязан к определенным спискам пользователей (например, к группе пользователей «aaa»), скорее, они могут на любом этапе жизненного цикла документа добавлять пользователей для общего доступа и аналогичным образом удалять пользователя, с которым предоставлен общий доступ к документу. Привилегии общего доступа могут быть как на чтение, так и на запись.
Ответ №1:
Я не использую область, но, глядя на эту документацию, я бы сказал, что для документов вы бы использовали общедоступное разделение с идентификатором документа в качестве префикса, аналогично тому, как обращаются с продавцами.
Тогда, я полагаю, вам нужно было бы иметь конечную точку на стороне сервера для совместного использования, которая записывала бы разрешенные идентификаторы документов всем пользователям, имеющим доступ к этим документам (конечная точка на стороне сервера сможет видеть полное представление данных, не ограничиваясь каким-либо одним пользователем).
Комментарии:
1. Спасибо, но я не думаю, что это сработает. Хотя вы можете назначить разрешения на чтение / запись на уровне документа, ключ раздела автоматически синхронизирует все данные в этой области вплоть до клиентских устройств, чего я пытаюсь избежать.