我是新手CouchDb，正在尝试理解如何正确使用它。我来自MongoDB我总是写一个 web 层并将它放在 mongo 前面的地方，这样我就可以允许用户访问其中的数据，等等。事实上，这就是我为每个人使用所有数据库的方式我曾经写过的网站。所以，看看 Couch，我发现它的原生 API 是 HTTP，并且它内置了诸如 OAuth 支持之类的东西，以及其他向我暗示也许我不应该再让我的代码层坐在 Couch 前面的功能，而是写Views和事情，只是把账户给我的用户？我正在考虑像我的站点的基于 HTTP 的 API，或者用户可以通过它使用我的数据的东西。不过，像这样打开沙发对我来说似乎很奇怪。在 Couch 的意义上，OAuth 是更多地用于远程访问我“正式”在我自己的网络内部编写和运行的软件，还是字面意思是最终用户？
我知道有些事情可能只能通过 CouchDB 之上的代码层来完成，比如如果您希望在 API 请求期间也发生其他与数据库无关的事情。所以沿着这些思路思考，我认为我仍然需要一个代码层，无论如何。
经销商的选择。
Nodejitsu 在这里有一篇关于这类主题的精彩文章。
不知道您的应用程序细节我会采取广泛的方法......
如果您想阻止用户看到您的数据库，请将其设置为后端。您可以通过 node.js 之类的东西对所有内容进行管道传输，并且只呈现用户需要查看的内容，而他们永远不会知道有关数据库的任何信息。请参阅资源视图演示者
如果您不关心数据安全，您可以在 CouchDB 上托管整个应用程序；见CouchApp。这种方法的好处是使用复制机制来控制发布您的站点/数据。这里的缺点是您几乎肯定会遇到一些技术限制，需要将 CouchDB 移到更靠近后端的位置。
让应用服务器呈现接口，客户端分别从数据库中提取数据。这提供了最大的灵活性，但可能会造成伤害，因为即使设计良好，这也可能导致可支持性和可扩展性问题。
在后端使用 CouchDB。如果您需要移动客户端进行同步，请为此目的使用公开公开的辅助数据库，并有选择地将这些数据同步到需要去的任何地方。
简单地说，没有。
没有办法在面向公众的网站上正确保护 Couch。没有办法在足够精细的级别上区分访问。如果有人可以访问任何数据，他们就可以访问所有数据。
并非网站上的所有数据都是供公众使用的，除了最琐碎的网站。