Я понимаю, что недостаток в сохранении нескольких видов в одном и том же проектном документе. Он будет перестраивать все индексы с нуля, если обновляется проектный документ. В чем преимущество сохранения нескольких видов в одном и том же проектном документе?CouchDb один проект doc со многими представлениями или многие документы по дизайну с видом
Он будет перестраивать все индексы с нуля, если обновляется проектный документ.
Не с нуля. Из моего опыта и того, что я прочитал о views cleanup, я понял, что каждый файл вида назван в честь хеша его определения. Итак, когда модифицируется проектный документ, все представления обновляются, вы правы, НО, если ни их определение, ни данные не изменились, обновление немедленно. Чтобы получить дальнейшее, если вы измените определение вида, а затем измените его на исходное определение, старый файл будет использоваться так, чтобы представление не вычислялось с нуля.
Проблема в другом месте. Каждый раз, когда запрос запрашивается, все представления обновляются. По моему опыту, это может быть проблемой, когда у вас есть как «маленькие» виды (с небольшим количеством выбросов на документ, небольшие клавиши, мало или без значений) и «большие» представления. Даже если вам просто нужен результат из небольших представлений (например, для просмотра ваших данных), вам придется ждать вычисления больших представлений.
В чем преимущество сохранения нескольких видов в одном и том же проектном документе?
Главное преимущество этого заключается в том, что виды являются частями одного и того же «приложения». Wether это настоящее веб-приложение или HTTP API, вы можете иметь согласованный набор URI через rewrite.
Еще одно преимущество, которое является частью «половины полного стекла» в том недостатке, о котором я упоминал ранее, заключается в том, что представления обновляются чаще и поэтому вычисляются постепенно. Поэтому есть больше шансов, что при запросе представления обновление будет выполнено быстрее.