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

Есть два способа его хранения. Либо в одном документе, содержащем подходящее представление данных в формате JSON, либо сохраните каждую часть записи в отдельном документе, объединяя их позже через представление (аналогично этому:http://www.cmlenz.net/archives/2007/10/couchdb-joins)

Теперь оба подхода могут быть хорошими, но, с моей точки зрения, оба имеют серьезные недостатки. Хранение занятого документа (ожидается много изменений от нескольких пользователей) в качестве объекта подписи, что может привести к возникновению конфликтов. Если пользователь A сохраняет свои изменения в документе, пользователь B получит сообщение об ошибке конфликта, как только он / она закончит вводить свое обновление. Я могу себе представить, что это можно исправить без ведома пользователей путем повторной загрузки документа перед повторной попыткой.

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

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

Хорошо, теперь давайте посмотрим на подход с несколькими документами. Вопрос, ответы и комментарии будут храниться в собственных документах. Преимущество: только фактический владелец документа может вызвать конфликты, что случается не так часто. Будучи довольно маленькими элементами целого, повторная загрузка не займет много времени. Кроме того, процедура аутентификации должна быть довольно простой для реализации.

Теперь вот обратная сторона. Один документ действительно легко запрашивать и отображать. Наличие большого количества несортированных фрагментов, лежащих вокруг, кажется грязной вещью, так как у меня не было реального представления, чтобы представить мне полностью готовый к использованию объект JSON, содержащий весь элемент в упорядоченном и структурированном формате.

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

Большое спасибо за вашу помощь заранее :)