CouchDB: единый документ против «объединения» документов вместе
Я пытаюсь выбрать лучший подход для CouchApp (без промежуточного программного обеспечения). Поскольку есть сходство с моей идеей, предположим, что у нас есть страница stackoverflow, хранящаяся в CouchDB. По сути, он состоит из собственно вопроса сверху, ответов и комментариев. Это в основном три слоя.
Есть два способа сохранить его. Либо в одном документе, содержащем подходящее представление данных JSON, либо сохраните каждую часть записи в отдельном документе, объединяя их позже в представлении (аналогично этому: http://www.cmlenz.net/archives / 2007/10 / couchdb-joins )
Оба подхода могут быть хорошими, но оба имеют огромные недостатки с моей текущей точки зрения.Сохранение загруженного документа (ожидается много изменений от нескольких пользователей) в качестве единственного объекта может вызвать конфликты. Если пользователь A сохраняет свои изменения в документе, пользователь B получит сообщение об ошибке конфликта, как только он / она закончит вводить свое обновление. Я могу представить, что можно исправить это без ведома пользователей, повторно загрузив документ перед повторной попыткой.
А что, если документ немаленький? Я замечаю, что они со временем станут довольно взорванными, что приведет к довольно заметной задержке процесса сохранения, особенно если процесс повторной попытки должен происходить несколько раз из-за того, что многие пользователи обновляют документ одновременно.
Еще одна проблема, с которой я столкнулся, - это редактирование. Каждому пользователю должно быть разрешено редактировать свой вклад. Теперь, если они хранятся в одном документе, может быть сложно написать надежный обработчик аутентификации.
Хорошо, теперь давайте посмотрим на подход с несколькими документами. Вопросы, ответы и комментарии будут храниться в их собственных документах. Преимущество: только фактический владелец документа может вызывать конфликты, что случается не слишком часто. Будучи довольно мелкими элементами целого, повторная загрузка не займет много времени. Кроме того, процедура аутентификации должна быть довольно простой в реализации.
Теперь обратная сторона медали. Один документ очень легко запросить и отобразить. Наличие большого количества несортированных фрагментов, лежащих вокруг, кажется беспорядочным, поскольку я действительно не получил фактического представления, чтобы представить мне 100% готовый к использованию объект JSON, содержащий весь элемент в упорядоченном и структурированном формате.
Надеюсь, мне удалось сообщить о реальной проблеме.Я пытаюсь решить, какое решение мне больше подходит, какие проблемы легче преодолеть. Я полагаю, что первое решение будет более красивым с точки зрения хранения и запросов, а второе - более практичным, которое можно решить за счет лучшего управления ключами в представлении (я еще не полностью разбираюсь в принципе ключей).
Заранее большое спасибо за вашу помощь :)