PouchDB - структура документа, если некоторые поля будут обновлены больше, чем другие

Question

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

1) У каждого ресурса есть универсальные поля, такие как имя, гражданский адрес, почтовый индекс, описание. Они будут иногда обновляться, а иногда и никогда не обновляться. Также можно добавить новые ресурсы.

2) В каждом ресурсе также есть несколько более часто обновляемых полей: новые ресурсы могут быть добавлены к новым ресурсам. И пользователям не нужно входить в систему, чтобы добавлять новые отзывы. Они могут сделать это без проверки подлинности.

Как мне создать базу данных или документы, чтобы я мог надежно позволить людям добавлять отзывы на каждый ресурс без проверки подлинности? Я рассматриваю возможность хранения относительно статических полей (описание имени ресурса) в качестве одного документа, а отзывы/оценки в качестве отдельных документов - это жизнеспособный способ? Похоже, что это было бы более безопасно, поскольку пользователи не могли бы изменять весь ресурс каждый раз, когда добавляли новые отзывы, и вместо этого они просто добавляли новые документы. Однако я не уверен, как это повлияет на производительность.

(Я смотрел разговоры Джоана Тузета о 10 распространенных заблуждениях, и это было полезно. Если кто-нибудь может указать мне на какой-то еще контент/примеры того, как структурировать мои документы и базы данных в PouchDB, чтобы максимально упростить/обеспечить безопасность, я бы действительно ценю это!)

заранее спасибо

Answer 1

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

Да, абсолютно!

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

И вот почему. ;-)

С этой конструкцией вы также избегаете конфликтов, будь то немедленные ответы на вопросы, когда несколько пользователей или возможные конфликты, когда вы переходите к нескольким реплицируемым базам данных. Также документы становятся намного проще.

Имейте в виду, что вы должны скопировать некоторую базовую информацию об ресурсе сообщества в каждый обзорный документ. Вполне возможно, что один пользователь (администратор) удаляет документ «ресурс», но пользователи не хотят, чтобы их рейтинги исчезали в виде временной шкалы. Например. скопируйте файл _id и url ресурса в каждый обзор.

Однако я не уверен, как это повлияет на производительность.

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

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