意识到this discussion，还有一个额外的旋转。
目前正在讨论组织中工程师的标题问题。
一方面，人们认为将非关系数据库（即CouchDB）挂钩到生产服务器永远不是一个好主意。他的架构建议是引入一个中间关系数据库作为两者之间的一种缓冲层（他特别推荐SQLAlchemy作为Postgres-＆gt; Flask / Django之类的ORM）
另一方面，另一位工程师认为，鉴于我们（相对较低的）网页浏览量，我们可以直接在CouchDB中完成所有工作。
我很想了解更多关于nonrelational -> relational -> web page架构与nonrelational -> web page的优缺点。
答案 0 :(得分：1)
将非关系数据库（即CouchDB）挂钩到生产服务器永远不是一个好主意
这对我来说听起来很危险。
我根本没有意识到在CouchDB和您的Web服务之间使用关系数据库的任何理由。什么是'缓冲'数据库？什么是CouchDB不是给你的？或者为什么要使用CouchDB，如果你可以使用关系数据库？
我能想到的唯一半合法的论点是你需要它，因为你有一些你的数据需要的关系建模，你必须转换到关系数据库才能正确地做到这一点，并提供一个理智的界面到您的网络服务。在这种情况下，您应该只使用一个关系数据库独立（或图形数据库，或其他东西，但不是文档存储）。
另一方面，有很多论据反对，包括：涉及的数据重复，数据冲突的可能性，然后必须以某种方式找到和修复，建立和维护额外的系统以监控两个的额外复杂性数据库并使它们保持同步，在两种数据建模方式之间进行转换的挑战，以及CouchDB的许多好方面的否定（灵活的模式，数据复制没有单点故障，任意结构化数据，易于扩展，方便的HTTP接口等）
我目前正在开展一项业务，该业务刚刚成功部署了大约20个CouchDB，分布在尽可能多的数据中心，由数千台服务器连续使用，每天为数百万用户提供服务。它绝对是生产就绪的，我不知道任何实质性的性能或可靠性问题（只要你知道你在基础设施设置方面做了什么）。