Принципы помещения представлений в один и тот же проектный документ в CouchDB?

Question

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

Answer 1

Внутри происходят следующие вещи.

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

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

3. Каждое обновление в базе данных должно проходить все validate_doc_update() функции из всех проектных документов в базе данных.

По этим причинам лучше рассматривать один проектный документ как одно приложение.

Единственное исключение, которое я лично использую, - это документ _design/couchdb, который имеет общие представления, например, показывает мне все конфликты документов.

Answer 2

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

Руководство содержит некоторую информацию о том, как правильно разместить проектную документацию.