嗨，我读到了两种为 couchapps 实现按文档读取访问的方法:
每个用户都有自己的数据库，其中只包含该用户可以读取的数据。然后所有用户写入主数据库，该数据库使用复制过滤器复制到所有用户数据库，该过滤器决定谁可以读取什么。 使用列表函数过滤其他 View 的输出并通过代理服务器和白名单限制访问。 我对此有一些疑问:
是否有更多的可能性来实现文档级别的读取访问？ 如何在 couchapp 中创建用户私有(private)数据库？我确实需要管理员权限，但填写我的应用程序注册表单的用户显然没有管理员权限。我是否需要用于注册过程的中间层(php 等)，以便我可以创建所需的数据库？ 当我最终拥有这个数据库时，我需要使用过滤器开始连续复制。我在某处读到，当服务器重新启动时，此类复制不会恢复。如果服务器崩溃，我是否需要一个 chronjob 每隔 x 小时重新创建这些复制？ 这不是对磁盘空间的巨大浪费吗？对于注册我的应用程序的每个用户，大部分数据都会重复，还是我错了？ (特别是如果只有很少的信息不能被别人阅读)
除了例如修改 CouchDB 源代码之外，我不知道有其他方法可以立即使用。一种可能性是使用可能具有 externals API 的主干(或发布时的 v1.1)。 .外部是 CouchDB 将一些连接转发到的 Web 服务器。 您需要一个 第三层，但不一定是中间层。您的外部软件将以管理员身份连接到 CouchDB 并执行待处理的任务。例如，当用户需要一个新的数据库时，他们在公共(public)数据库中创建一个文档，然后外部软件将创建数据库，将用户分配为管理员等。通过查询 /_changes?feed=continuous 很容易做到这一点。因为您可以从用户那里获得实时更新。我更喜欢这个而不是中间层，因为软件更简单(没有额外的 Web 开发，只有 CouchDB GET 和 PUT)，它可以崩溃、重启、升级等，对用户没有太大影响。 无论如何，cron 工作都不是一个坏主意。嘿，它可能是上面第 2 步中外部处理器的一部分!但是，从 CouchDB 1.1 开始，复制将在沙发重启后重新启动。 它不应该浪费太多空间。根据您的应用程序，您希望获取共享数据库中的所有共享数据，以及每个用户的私有(private)数据库中的所有私有(private)数据。但即使你有重复的数据，我也不会称之为浪费。与开发人员的努力或安全问题的无形成本相比，磁盘空间是一笔非常小的开支。 根据您的应用，您有
巨大的 future 移动或离线功能的机会。当您发布 iPhone、桌面或离线 web 应用程序时，用户可以在其数据库的本地副本上工作，然后在他们重新在线后与您服务器上的“官方”数据库同步。对于某些应用程序，这正成为人们希望在任何情况下使用应用程序的必备功能。