什么时候不应该使用关系数据库？[关闭]

除了google / bigtable方案之外，您什么时候不应该使用关系数据库？为什么不呢？您应该使用什么呢？（您学习过“艰难的方式”吗？）

以我的经验，当满足以下任一条件时，您不应使用关系数据库：

• 您的数据被构造为任意深度的层次结构或图形（网络），
• 典型的访问模式强调阅读而非写作，或者
• 不需要即席查询。

深层次结构和图形无法很好地转换为关系表。即使在诸如Oracle的专有扩展的帮助下CONNECT BY，使用SQL追逐树也是巨大的痛苦。

关系数据库为简单的读取访问增加了很多开销。事务性和引用完整性很强大，但是对于某些应用程序来说却是过大的。因此，对于只读应用程序，文件隐喻就足够了。

最后，如果没有意外的查询，您根本不需要具有成熟查询语言的关系数据库。如果没有人提出这样的问题，例如“在销售员的协助下，我们在东海岸出售了多少折价为5％的蓝色小部件？”，然后再也没有了，那么，先生，您可以免费居住。

关系数据库范例对数据的使用进行了一些假设。

• 关系由一组无序的行组成。
• 关系中的所有行都具有相同的列集。
• 每列在所有行上都有固定的名称，数据类型和语义。
• 关系中的行由主键列中的唯一值标识。
• 等等

这些假设以一些灵活性为代价来支持简单性和结构。并非所有的数据管理任务都适合这种结构。例如，具有复杂属性或可变属性的实体就没有。如果在关系数据库解决方案不支持的领域中需要灵活性，则需要使用另一种解决方案。

还有其他解决方案可用于管理具有不同要求的数据。例如，语义Web技术允许通过将元数据作为属性像数据一样对待，每个实体定义自己的属性并进行自我描述。这比关系数据库所强加的结构更灵活，但是这种灵活性要付出代价。

总体而言，您应该为每个作业使用正确的工具。

另请参阅我对“下一代数据库”的其他回答。

有三个主要的数据模型（CJDate，EFCodd），我为此添加了一个平面文件：

• 平面文件（结构各异-从“愚蠢”的平面文本到符合语法的文件，再加上巧妙的工具，它们可以完成非常聪明的事情，认为编译器及其作用，缩小对新事物建模的应用范围）
• 层次结构（树，嵌套集-示例：xml和其他标记语言，注册表，组织结构图等；可以建模），但是完整性规则不易表达，检索很难自动优化，某些检索速度很快，有些则非常慢 ）
• 网络（网络，图形-示例：导航数据库，超链接，语义网，几乎所有模型都可以建模，但是自动优化检索是一个问题）
• 关系（一阶谓词逻辑-示例：关系数据库，自动优化检索）

层次和网络都可以用关系表示，而关系可以用其他两个表示。

关系被视为“更好”的原因是声明性和标准化，不仅涉及数据检索语言，还涉及数据定义语言，包括强大的声明性数据完整性，并具有稳定，可扩展的多用户管理系统作为备份。

效益是以成本为代价的，大多数项目发现该系统对于存储长期数据的系统（多应用程序）是一个很好的比例，并且可以在可预见的将来使用。

如果您不是在构建一个系统，而是一个应用程序（可能是一个用户），并且可以肯定的是，很快就不会再有多个应用程序使用您的数据或多个用户，那么您可能会发现更快的方法。

另外，如果您不知道要存储哪种数据以及如何对其建模，那么就会浪费关系模型的优势。

或者，如果您根本不关心数据的完整性（这可能很好）。

所有数据结构都针对某种用途进行了优化，只有在正确建模的情况下，关系数据才会尝试以语义无偏的方式表示“现实”。对关系数据库有不良经验的人通常不会意识到其他类型的数据模型的经验会更糟。可怕的实现是可能的，尤其是在关系数据库中，建立相对复杂的模型相对容易，最终可能会遇到很多麻烦。当我尝试在xml中想象同样的怪物时，我仍然总是感觉更好。

IMO是一个很好的关系模型的例子，它是您将发现涉及SQL的问题的复杂程度与简短程度之比。

我建议您访问High Scalability博客，该博客几乎每天都在讨论该主题，并且有许多文章介绍了通过RDMBS选择分布式哈希等的项目。

快速（但非常不完整的答案）是，并非所有数据都能以有效的方式很好地转换为表。例如，如果您的数据本质上是一个大词典，那么可能有比普通RDBMS更快的替代方法。话虽如此，这主要是性能问题，如果性能不是项目中的大问题，例如稳定性，一致性和可靠性，那么在什么时候深入研究这些技术没有多大意义。 RDBMS是一个更为成熟和完善的方案，它支持所有语言和平台，并提供大量解决方案供您选择。

十五年前，我正在研究信用风险系统（基本上是大树行走系统）。我们在HPUX和solaris上使用Sybase，而性能却使我们丧命。我们直接从Sybase聘请了顾问，他们说这无法完成。然后我们切换到OO数据库（在这种情况下为对象存储），性能提高了约100倍（并且代码也更容易编写约100倍）

但是这种情况很少见-关系数据库是一个不错的首选。

当架构变化很大时，您将很难使用关系数据库。这是XML数据库或键值对数据库最有效的地方。或者您可以使用IBM DB2并通过单个数据库引擎来管理关系数据和XML数据。

大约7到8年前，我在一个网站上工作，该网站的受欢迎程度超出了我们的最初预期，并且使我们在性能方面遇到麻烦。由于我们都相对缺乏基于Web的项目的经验，因此，除了常规的数据库分离到单独的服务器，负载平衡等之外，我们该做什么。

有一天，我想到了一件非常简单的事情。由于网站是基于用户的，因此他们的个人资料以某人通常的方式存储在数据库表中-用户ID，大量信息变量和类似内容-会显示为用户个人资料页面，其他用户可以查找。我已经将所有数据刷新到一个简单的html文件中，该文件已作为用户个人资料页面进行了准备，并得到了显着提升-基本上是一个缓存。我什至制作了一个系统，当用户编辑其个人资料信息时，它将解析原始的html文件，将其放置以进行编辑，然后将html刷新回文件系统-进一步提高了效率。

我使用用户彼此发送的消息进行了类似的描述。基本上，只要我能使系统完全绕开数据库，而避免INSERT或UPDATE，我都会得到极大的提升。这听起来像是一个常识，但这是一个启发性的时刻。它本身并不是在避免建立关系，而是完全是在避免数据库-KISS。