使用“面向文档的 DBMS”有什么好处？
我一定错过了一些东西，因为到目前为止我所看到的一切都表明它并不比用于存储 blob 的单个表和用于存储适用于它的标签的第二个表更有趣。
现在我当然可以从设计模式中看到一些好处，但为什么我要使用“面向文档的 DBMS”，而不是仅仅使用 SQL Server、Oracle 或 Postgres 等传统数据库来构建它？
I must be missing something, because everything I've seen so far suggests that it isn't any more interesting than a single table for storing blobs and a second table for tags that apply to it.
Now I certainly can see some benefit to that from a design pattern, but why would I want to use a "document-oriented DBMS" instead of just building it using a traditional database like SQL Server, Oracle, or Postgres?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我很喜欢听关于 CouchDB 的 floss 每周一集。那里有很多推理和想法。
在听之前，我读到的关于这个主题的大部分内容并没有引发太多的见解（对我来说）。听人们谈论和推理为什么要使用面向文档的数据库以及在哪里使用面向文档的数据库，这对我真正了解概念、推理、优点和缺点有很大帮助。现在所有的文章和声明（恕我直言）突然变得更有意义了。
你的里程可能会有所不同，但这对我帮助很大。
I enjoyed listening to the floss weekly episode about CouchDB. Lots of reasoning and ideas there.
Prior to listening, most of the stuff I read about this topic triggered not much insight (for me). Listening to people talking and reasoning about why&where you want to use document-oriented DBs helped me a lot to really get the concepts, reasoning, pros and cons. Now all the articles and statements (IMHO) suddenly make a lot more sense.
Your mileage may vary, but this helped me a lot.
我猜您指的是 Couch DB 或 Tokyo Cabinet 等产品（而不是 Documentum 等 ECM 产品）。我认为对于许多开发者来说，吸引力在于熟悉。
首先，概念模型（在大多数情况下）是键值对，就像配置文件一样。由于大多数框架似乎需要大量的配置争论，前端/中间层开发人员对这种工作方式感到满意。其次，这些工具以 Java、Python 等开发人员友好的语言提供界面。
而传统的 RDBMS 产品需要以不同的方式进行思考——关系。他们不仅需要学习一种奇怪的语言 SQL，还需要学习一种新的编程方式：基于集合而不是过程。如果您演练将业务逻辑放在中间层而不是数据库中的存储过程的论点，那么其中很多也适用于 No SQL。
I presume you are meaning products such as Couch DB or Tokyo Cabinet (rather than ECM products like Documentum). I think the attraction for many developers is familiarity.
Firstly, the conceptual model (in most cases) is key-value pairs, like a configuration file. As most frameworks seem to require a lot of configuration-wrangling, front-end/middle tier developers are comfortable with that way of working working. Secondly, these tools offer interfaces in developer-friendly languages like Java, Python, etc.
Whereas, traditional RDBMS products require thinking in a different fashion - relationally. And they require learning not just a weird language, SQL, but a new way of programming: set-based rather than procedural. If you rehearse the arguments for putting business logic in the middle tier rather stored procedures in the database, well a lot of them apply to No SQL as well.
历史上面向文档的 DBMS 不允许跨文档跨越 ACID 事务。他们对外键的支持很差。该行业应该允许更容易的操作、维护和扩展。
Historically document-oriented DBMS do not allow to span ACID transactions across documents. They have poor support for Foreign Keys. The trade ought to allow for more accessible operations, maintenance and scaling.