Вариант использования
- Я хочу обслуживать нескольких клиентов от 1 couchdb
- Каждый клиент будет иметь свой собственный набор данных (и подмножество дочерних элементов)данные - головной офис как родитель и каждое местоположение как дети)
- У каждого клиента могут быть разные экраны пользовательского интерфейса
- Внутри каждого клиента разные пользователи могут иметь разные экраны пользовательского интерфейса
- Система будет работать в одном месте и будет распространяться по всему миру и будет использовать репликацию
Опции
Для каждого клиента храните все страницы в одном _designдокументировать и обслуживать соответствующие страницы в зависимости от типа пользователя (разрешения)
Для каждого клиента хранить каждую страницу в своем собственном _design документе
Для каждогоклиент, сохраните все страницы, связанные с уровнем разрешений пользователей, в одном документе _design, чтобы каждый тип пользователя обслуживался из другого документа _design
Кроме того, я прочитал два документа.ooks теперь на couchDB, и до сих пор не ясно преимущества использования документа _design по сравнению с обычным документом для обслуживания веб-страниц.
UPDATE 1:
Я думаю, что я будунужно привести более четкий пример.
Компания A имеет головной офис в Бангкоке с руководством и административным (секретарским) персоналом, использующим приложение.Эти пользователи будут принадлежать к разным группам пользователей и иметь разные разрешения, которые будут предоставлять им доступ к разным документам HMTL (или к одному и тому же документу-шаблону, но с разным контентом через js).Эта компания имеет офисы в Паттайе, Пхукете и Чанг Май.В каждом из этих офисов есть разные типы пользователей, которые будут иметь доступ к разным частям приложения и видеть разные версии экранов HTML.Локальные приложения будут основаны на отфильтрованной репликации.
Этот couchDB будет предоставлять эту услугу нескольким компаниям, структурированным так же, как Компания A, и все из одного и того же БД (причина в том, что нам нужно иметь возможность агрегировать данные для всех компаний, а couchDB не может агрегировать по нескольким базам данных, так как представленияспецифичны для БД, если я правильно читаю.) Однако каждая основная компания может иметь небольшие отличия от своих HTML-страниц от других основных компаний.
Поэтому, фокусируясь только на структуре, моя первоначальная идея состоит в том, чтобы создать несколько документов _designдля каждой основной компании.В каждом из этих _design документов мы храним каждую HTML-страницу для этой компании (которая может совпадать или не совпадать с другими основными компаниями.
Есть ли лучший способ структурировать это? Видите ли вы проблемы с масштабированием?когда мы говорим 1000 ведущих компаний?
PS Даже если мы не можем завершить решение проблем ACL напрямую через couchDB, мы всегда можем сделать это сами, поэтому сейчас это не главное.
ОБНОВЛЕНИЕ 2:
Итак, после дополнительных исследований я вижу, как функции шоу (шоу) играют роль в этом с помощью шаблонов. Это не полностью отвечает на мой вопрос, поэтому я предполагаю, основываясь наэто, мне также интересно сейчас, есть ли когда-нибудь ситуация, когда вы могли бы хотеть иметь любое другое вложение HTML в документе _design, кроме index.html?