前端之家收集整理的这篇文章主要介绍了
什么时候面向文档NoSQL数据库可以代替SQL数据库，
前端之家小编觉得挺不错的，现在分享给大家，也给大家做个参考。
声明：
我相信任何技术既然被认可都有其用武之地，但是我们要扬长避短，切不可盲目崇拜。
我喜欢折腾自己没接触过的技术，并尝试用它去解决实际工作中遇到或可能遇到的问题，其中有成功也有失败，下面的总结也是来自最近的一次尝试的失败。
No
sql绝对不是用来取代关系
数据库，只有在某些特定情况下考虑只使用它来作为数据存储，但比应用广泛的关系
数据库来说，多数情况下这绝不是一件更容易的事情（想真正做好一件事情都不是容易的）。
自问自答，仅供参考。只使用面向文档的No
sql数据库来作为数据存储的场景：
从项目角度：
- 高度自治的项目，例如：
- 内部系统的一个公共组件/服务，只是为了支持某些特定的功能
- 你是神，当别人提出新需求，你只需说一句：”不支持！”，就能把他们打发走
- 一个发展成熟的项目急需Nosql提供的特点和能力，经过深思熟虑和仔细考察后的重构
- 自建小项目，用腻了关系数据库，打算尝尝Nosql的鲜，项目成功失败影响不大
- 如果你或你所在的组织对项目业务需求和发展方向没有太清晰的规划，只是想先让它跑起来，然后不断的迭代下去，那么也不应该使用Nosql
- 你很确定这个项目在不久的将来会获得极大的成功，需要存储大量的数据，并且在项目开发阶段你有能力投入更多的资源，人力，物力和时间。并且这些投入与项目成功时所获得的回报相比是值得的。
- 这个项目就是来练手的，Nosql不合适时有条件使用关系数据库推倒重来
从数据角度：
数据之间不存在关联关系，或可预见的很长时间内保证无关系。数据的价值不会体现在关联关系上。
项目成员对业务有经验、有意愿并且有能力分析/预测业务场景和需求，针对重点业务对数据进行”No
sql式"的建模，在读写之间，在不同读之间寻找一个合适的平衡点，设计出最适合的JSON文档来保存数据。
根本就不关心里面保存什么数据，你关心的是volume与velocity，你只是负责保存下来，之后提供给能够使用这些数据的系统或服务
