Блог

Пример использования

• Я хочу обслуживать несколько клиентов из 1 couchdb
• У каждого клиента будет свой собственный набор данных (и подмножество дочерних данных — головной офис в качестве родительского и каждое местоположение в качестве дочернего)
• У каждого клиента могут быть разные экраны пользовательского интерфейса
• У каждого клиента разные пользователи могут иметь разные экраны пользовательского интерфейса
• Система будет представлять собой couchapp, распределена по всему миру и будет использовать репликацию

Параметры

• Для каждого клиента сохраняйте все страницы в одном документе _design и обслуживайте соответствующие страницы на основе типа пользователя (разрешения)

• Для каждого клиента сохраняйте каждую страницу в собственном документе _design

• Для каждого клиента храните все страницы, связанные с уровнем прав доступа пользователя, в одном документе _design, чтобы каждый тип пользователя обслуживался из другого документа _design

Кроме того, сейчас я прочитал две книги по CouchDB, и до сих пор неясно, в чем преимущества использования документа _design в отличие от обычного документа для обслуживания веб-страниц.

ОБНОВЛЕНИЕ 1:
Я думаю, мне нужно будет привести более наглядный пример.

У компании A есть головной офис в Бангкоке, где руководство и административный персонал (секретари) используют приложение. Эти пользователи будут принадлежать к разным группам пользователей и иметь разные разрешения, которые обеспечат им доступ к разным документам HMTL (или к тому же шаблонному документу, но предоставляющему разный контент через js). Эта компания имеет офисы в Паттайе, Пхукете и Чангмае. В каждом из этих офисов работают разные типы пользователей, которые будут иметь доступ к разным частям приложения и видеть разные версии HTML-экранов. Локальные приложения будут основаны на отфильтрованной репликации.

Этот CouchDB предоставит эту услугу нескольким компаниям, структурированным точно так же, как Company A, все из одной базы данных (причина в том, что нам нужно иметь возможность агрегировать данные для всех компаний, а CouchDB не может агрегировать по нескольким базам данных, поскольку представления зависят от базы данных, если я правильно прочитал.) Однако у каждой основной компании могут быть небольшие отличия в их HTML-страницах от других основных компаний.

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

Есть ли лучший способ структурировать это? Видите ли вы проблемы с масштабированием, когда у нас, скажем, 1000 основных компаний?

P.S. Даже если мы не можем решить проблемы ACL напрямую через CouchDB, мы всегда можем сделать это сами, так что сейчас это не является первостепенной задачей.

ОБНОВЛЕНИЕ 2:
Итак, после дополнительных исследований я вижу, какую роль в этом играют функции show (шоу) с использованием шаблонов. Это не дает полного ответа на мой вопрос, поэтому, я полагаю, исходя из этого, мне также интересно, возникала ли когда-либо ситуация, когда вы могли бы захотеть иметь какое-либо другое HTML-вложение в документе _design, отличное от index.html ?

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

1. Используйте веб-уровень среднего уровня. Это похоже на любую другую архитектуру MySQL / PHP или Rails. CouchDB — это серверная часть данных. У вас есть свои собственные логины пользователей и управление, и вы все делаете сами.
2. Используйте модель безопасности CouchDB. Это требует некоторого обучения, но, эй, вы не пишете свой собственный код пользователя и аутентификации самостоятельно. Чтобы иметь разные наборы данных для разных пользователей, у каждого пользователя есть своя база данных, и вы реплицируете (используя фильтр) только те документы, которые пользователь может видеть.

CouchDB напрямую обслуживает все запросы из Интернета. Неважно, был ли клиент браузером (Couch app), iPhone или cURL командной строки. Проектные документы вообще не влияют на разрешения базы данных на чтение.

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

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