什么时候不应该使用关系数据库？
除了google / bigtable场景，何时不应该使用关系数据库？ 为什么不，你应该使用什么？ （你是否学习'艰难的道路'？）
根据我的经验，当这些条件中的任何一个为真时，您都不应该使用关系数据库：
深层次结构和图形不能很好地转换为关系表。 即使在像Oracle的CONNECT BY这样的专有扩展的帮助下，使用SQL追查树木也是非常痛苦的。
关系数据库为简单的读取访问增加了很多开销。 事务和参照完整性是强大的，但对于某些应用程序来说是过度的。 所以对于大多数应用程序来说，文件隐喻就足够了。
最后，如果没有预料到的意外查询，您完全不需要具有全面查询语言的关系数据库。 如果没有诉讼提出问题，例如“我们在东海岸按销售员分组销售多少5％的蓝色小工具？”，那么您先生可以免费领取数据库。
关系数据库范例对数据的使用做出了一些假设。
这些假设支持简单和结构，但要以一定的灵活性为代价。 并非所有的数据管理任务都适合这种结构。 例如，具有复杂属性或可变属性的实体不会。 如果您在关系数据库解决方案不支持的领域需要灵活性，则需要使用其他类型的解决方案。
还有其他解决方案用于管理具有不同要求的数据。 例如，语义Web技术允许每个实体定义自己的属性，并且通过将元数据视为像数据一样的属性来进行自我描述。 这比关系数据库强加的结构更灵活，但这种灵活性带来了自己的成本。
总的来说，你应该为每项工作使用正确的工具。
另见我对“下一代数据库”的其他答案。
我建议您访问高可扩展性博客，该博客几乎每天都会讨论这个主题，并且有许多关于通过RDMBS选择分布式散列等的项目的文章。
快速（但非常不完整的答案）是，并非所有数据都能以有效的方式很好地转换成表格。 例如，如果您的数据本质上是一个大字典，那么可能会有更快的替代方案，即简单的旧RDBMS。 话虽如此，它主要是一个性能问题，如果性能不是一个项目中的重大问题，并且例如稳定性，一致性和可靠性，那么当我研究这些技术时，我并没有多少意见RDBMS是一种更为成熟和发展完善的方案，支持所有语言和平台以及一系列可供选择的解决方案。
链接地址: http://www.djcxy.com/p/93871.html