正确构建couchDB应用程序

Question

用例

• 我想从1 couchdb服务多个客户
• 每个客户都有自己的数据集(以及子数据的子集 - 总公司作为父级,每个位置作为子级)
• 每个客户可以拥有不同的UI屏幕
• 在每个客户中,不同的用户可能具有不同的UI屏幕
• 该系统将是一个couchapp并分布在全球,并将使用复制

选项

• 对于每个客户,将所有页面存储在一个_design文档中,并根据用户类型(权限)提供相应的页面

• 对于每个客户商店,每个页面都有自己的_design文档

• 对于每个客户,将与用户权限级别关联的所有页面存储在一个_design文档中,以便从不同的_design文档中提供每个用户类型

此外,我现在在couchDB上阅读了两本书,并且仍然不清楚使用_design文档而不是普通文档来提供网页的优势.

更新1:
我想我需要提供一个更清晰的例子.

A公司在曼谷设有总部,管理和行政(秘书)工作人员使用该应用程序.这些用户将属于不同的用户组,并具有不同的权限,这将允许他们访问不同的HMTL文档(或相同的模板文档,但通过js提供不同的内容).该公司在芭堤雅,普吉岛和昌迈设有办事处.在每个办公室,他们都有不同的用户类型,他们可以访问应用程序的不同部分,并查看不同版本的HTML屏幕.本地应用程序将基于过滤的复制.

这个couchDB将为公司A之类的多个公司提供这项服务,所有这些公司都来自同一个数据库(原因是我们需要能够为所有公司汇总数据而且couchDB不能在多个数据库之间聚合,因为如果我阅读的话,视图是特定于数据库的但是,每个主公司可能与其他主公司的HTML页面略有不同.

因此,仅关注结构,我最初的想法是做多个_design文档,每个主公司一个.在每个_design文档中,我们存储该公司的每个HTML页面(可能与其他主公司相同或不同).

有没有更好的方法来构建它？当我们说1000家大公司时,您是否看到了扩展问题？

PS即使我们不能通过couchDB直接完成解决ACL问题,我们也可以自己做,所以这不是现在的主要问题.

更新2:
经过更多研究后,我看到节目功能(节目)如何通过使用模板在这方面发挥作用.它没有完全回答我的问题,所以我想,基于此,我现在还想知道是否有一种情况你可能希望在_design文档中除index.html之外还有任何其他HTML附件？

Answer 1

针对多个用户的情况有两种基本解决方案,每种解决方案只能看到总数据的一个子集.

1. 使用中间Web层.这就像任何其他MySQL/PHP或Rails架构一样.CouchDB是一个数据后端.您拥有自己的用户登录和管理,并自己完成所有工作.
2. 使用CouchDB安全模型.它需要一些学习,但是,嘿,你不是自己编写自己的用户和身份验证代码.要为不同的用户提供不同的数据集,每个用户都有自己的数据库,您只能复制(使用过滤器)用户可以看到的文档.