文档型数据库相对关系数据库的缺点是啥
首先，一致性问题和是否采用文档型存储是没有关系的。一致性问题是由于系统既要保证分布式又要求高性能导致的。说白了就是数据不同步，目前文档型数据库如MongoDB并没有说在一致性上有多大问题。当前的文档型数据库以MongoDB和CouchDB发展最好，而二者除了在存储结构上都是文档型外（一个BSON，一个JSON），其它方面几乎没有什么相同的。下面再说几个点：ACID：MongoDB确实不提供跨Collection的事务保证，但其对每一个Document的操作都是原子性的，而CouchDB更是提供完整的ACID保证的。关联查询：MongoDB确实不能进行跨集合的JOIN操作，CouchDB由于只提供预先建立View的查询，其查询最终是通过MapReduce任务来做的。也是不支持关联查询的。稳定性：相对于发展了几十年的关系型数据库，其稳定性和成熟程度当然不能比，用之前还请三思。经验和工具：相对于成熟的关系型数据库，新兴的文档型数据库可能真正了解的人并不多，成熟的工具也不多，这也是个问题。可能导致你招不到合适的DBA。
■网友
【文档型数据库相对关系数据库的缺点是啥】 一般而言，谈到文档型数据库的优点，主要有以下三点：
（1）schema flexibility. 没有固定的schema，插入数据行灵活，对时常变更的应用友好，免去了关系数据库DDL之苦。
（2）locality. 相关的数据都是存在一起的，比如一个人曾在多家公司任职这样的信息，可以存在一行里，查询时只访问这一行就行了，但在关系数据库里，这样一对多的关系，往往涉及join。
（3）更加接近于应用端组织数据的方式，开发者用起来更加简单、易学。
但是，有得必有失，以上优点在某些情况下，也会带来负面影响。
诸如一个人任职过多家公司，一家公司的职员有多个，这样的多对多关系，关系型数据可以通过外键的方式关联起来。而文档数据库为了保持这种关系会非常麻烦。
假如个人信息是一个文档，包含了其任职多家；公司信息是个文档，包含了公司所有详细信息。需要查询某个人任职过的公司的所有信息时，需要在应用端代码实现“Join”的功能，是比较低效的。
当然你也可以在个人信息的文档里存储其任职过的公司的所有信息，但一来与公司信息文档的一致性难以维护，二来当你需要查询的仅仅是个人部分信息时，文档中的公司信息也会一并返回，造成较大浪费。
以上是文档型数据库在应用上的缺点，因此大家在做数据库选型的时候，可以根据业务特点选择使用文档型数据库还是关系型数据库。
此外大家翻看Oracle/MySQL/PG等关系型数据库的文档会发现，它们的功能非常丰富，诸如存储过程、触发器、事务、GIS等功能还是远远强于文档型数据库的。并且这些关系型数据库纷纷支持了XML、JSON等格式，用户也可以像使用文档数据库一样使用它们了。
■网友
两者的设计思路不同，本来就是为了在不同的业务场景下用
■网友
从数据结构出发对比关系型数据库和文档型数据库
■网友
就mongodb来说不支持多表查询，如果有需要要在应用中实现，可以通过文档嵌入的方式把多表数据存入一条数据中不支持acid事务，只保证单条数据的原子性和最终一致性，因此对于金融领域的数值计算是非常不适合的
■网友
①.现在的文档数据库对于一致性不能做到很好，或者说在保证性能的情况下一致性不能做到很多，所以说，一些对一致性要求高的还是要慎重一点。②.现阶段的文档数据库没有一个稳定的或者说是非常成功的应用，大家都还在摸索的时期（4sq就是最经典的例子），而一般的关系型数据库已经有很多成功的例子，有规律可循，不会发生严重的问题。
推荐阅读
- 考研数据库方向
- 哪个数据库，可以直接做数据透视图（navicat类的也可以）
- 目前哪些门户网站的新闻质量相对较高
- 动态规划能得到一类问题的最优解，比如背包问题用动态规划来解决，怎样证明这个解就是相对应问题的最优解呢
- 关于图片里的文本识别，哪些特征相对有效
- 范丞丞|《撒野》同框曝光，范丞丞王安宇四目相对，蒋丞顾飞的感觉有了
- |“文化配位”为何是解读雷克萨斯的钥匙？
- |细菌滋生 异味刺鼻 车内空气靠TA守护
- 哪里能获取美股月度成交金额的数据，找了好几个数据库都只有成交量
- 怎样看待公司各个产品的用户系统相对独立