Couch DB/Pouch Стратегия репликации DB по ролям пользователей

Question

Я разрабатываю мобильное приложение для управления задачами (список дел плюс множество дополнительных полезных свойств), которые можно использовать в автономном режиме и синхронизировать при повторном подключении. Я был впечатлен Couch и Pouch DB, но я до сих пор не уверен в лучшей структуре баз данных и ролей. Моя ситуация заключается в том, что у пользователя может быть много задач и задач, которые могут быть доступны для многих других пользователей (только для чтения) либо напрямую, либо путем назначения задачи группе, а затем совместного использования этой группы с конкретными пользователями.

После того, как вы прочитали следующий вопрос: CouchDB replication strategy with dynamic groups of users Я думаю, что я не могу позволить прямое совместное использование задачи и разрешать доступ только через группы. Тогда каждая группа эффективно играет роль в Couch, которую я могу затем управлять авторизацией. Я могу написать API из своего веб-приложения, чтобы мобильный пользователь мог получить список разделяемых им групп, а затем настроить одностороннюю репликацию из каждой группы на основе БД в их местный DB. Каждый пользователь также будет иметь доступ на чтение и запись к БД своих собственных задач с двухсторонней синхронизацией от Pouch to Couch. Будет отфильтрованная репликация из их собственного Couch DB для каждой базы данных на основе роли, к которой принадлежит задача.

Мои основные вопросы:

1. Является ли это действительная структура или есть недостатки в моей логике, что бы сделать это трудно?
2. Что было бы лучшим способом обработки, когда пользователь был удален из группы/роли и как удалить любые ранее реплицированные задачи в своей локальной папке DB теперь, когда группа больше не разделяется с ними (у них больше нет таких роль)?
3. Пользователь может удалить группу, которая будет означать, что вся БД, основанная на роли, должна быть удалена - есть ли какие-либо последствия этого?

Answer 1

Большие вопросы, Пол! Это, кажется, продолжает появляться в последнее время. :)

Является ли это допустимой структурой или есть недостатки в моей логике, которые затрудняют это?

думаю. Я отправил architecture diagram в качестве ответа на аналогичный рабочий процесс с поддержкой мобильных устройств (Cordova + PouchDB в этом случае).

Что было бы лучшим способом обработки, когда пользователь удалялся из группы/роли и как удалять любые ранее реплицируемые задачи в своей локальной папке DB теперь, когда группа больше не разделяет их (они нет более длинная роль)?

Вероятно лучший маршрут использовать View на базе данных пользователя, чтобы найти все документы, связанные с акциями/группой, а затем использовать фоновый процесс (или некоторые такой), чтобы удалить эти документы (для экономии места; Если вам нужно).

Вы можете использовать систему объемных документов in PouchDBor CouchDB с "_deleted": true, установленную в документах, что должно упростить процесс удаления.

Пользователь может удалить группу, которая будет означать, что вся БД, основанная на ролях, необходимо будет удалить - есть ли какие-либо последствия этого?

Просто не забудьте также удалить задачи репликации, чтобы избежать неудачных повторений после того, как база данных исчезла. В противном случае, вы должны быть в порядке (насколько я могу судить).

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