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