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

Question

除了google / bigtable场景之外，什么时候不应该使用关系数据库？为什么不，你应该用什么？ （你是否学到了“困难的方式”？）

Answer 1

根据我的经验，当这些条件中的任何一个为真时，您不应使用关系数据库：

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

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

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

最后，如果没有预期的意外查询，您根本不需要具有完整查询语言的关系数据库。如果没有套装提出问题，例如“我们在销售人员分组的东海岸销售了多少5％的折叠蓝色小部件？”，那么从来没有，那么，先生，您可以免于使用DB。

Answer 2

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

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

这些假设支持简单性和结构，但代价是具有一定的灵活性。并非所有数据管理任务都适合这种结构。例如，具有复杂属性或变量属性的实体不会。如果在关系数据库解决方案不支持的领域需要灵活性，则需要使用不同类型的解决方案。

还有其他解决方案可用于管理具有不同要求的数据。例如，语义Web技术允许每个实体定义自己的属性并自我描述，方法是将元数据视为属性，就像数据一样。这比关系数据库强加的结构更灵活，但这种灵活性带来了自己的成本。

总的来说，您应该为每项工作使用正确的工具。

另请参阅我对“The Next-gen databases。”的其他答案。

Answer 3

有三种主要的数据模型（C.J.Date，E.F.Codd），我正在为此添加一个平面文件：

• 平面文件（结构各不相同 - 从'愚蠢'的平面文本到符合语法的文件，再加上聪明的工具做非常聪明的事情，想想编译器及他们能做什么，缩小应用程序来建模新东西）
• hierarchical（树，嵌套集 - 示例：xml和其他标记语言，注册表，组织结构图等;任何内容都可以建模，但完整性规则不易表达，检索很难自动优化，有些检索很快，有些检查很慢）
• network（网络，图表 - 示例：导航数据库，超链接，语义网，几乎所有内容都可以建模，但自动优化检索是一个问题）
• relational（一阶谓词逻辑 - 示例：关系数据库，检索的自动优化）

层次结构和网络都可以用关系表示，关系可以用另外两种表示。

关系被认为是“更好”的原因是不仅对数据检索语言而且对数据定义语言的声明性和标准化，包括强大的声明性数据完整性，备份stable，可扩展，多用户管理系统。

效益是有代价的，大多数项目都认为这是一个很好的系统（多应用程序）比率，可以在可预见的将来使用长期数据。

如果你不是在构建一个系统，而是一个应用程序，可能只针对一个用户，并且你很确定你不希望多个应用程序使用你的数据，也不想要多个用户，那么你很快就会找到更快的方法。

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

或者，如果您根本不关心数据的完整性（可能没问题）。

所有数据结构都针对某种用途进行了优化，只有正确建模的关系试图以语义无偏的方式表示“现实”。对关系数据库有不良经验的人通常没有意识到他们的经验会因其他类型的数据模型而变得更糟。可怕的实现是可能的，特别是在关系数据库中，构建复杂模型相对容易，你最终可能会遇到很多怪物。当我试图想象xml中的同一个怪物时，我总是感觉更好。

良好关系模型的一个例子，即IMO，是您将发现涉及SQL的问题的复杂性与简短性的比率。

Answer 4

我建议您访问High Scalability blog，它几​​乎每天都会讨论这个主题，并且有许多关于通过RDMBS选择分布式哈希等项目的文章。

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

Answer 5

15年前，我正在研究信用风险系统（基本上是一个大树行走系统）。我们在HPUX上使用Sybase＆amp; solaris和表演正在杀死我们。我们直接聘请了Sybase的顾问，他们表示无法完成。然后我们切换到一个OO数据库（在这种情况下是对象存储）并且性能提高了大约100倍（并且代码也更容易编写100倍）

但是这种情况非常罕见 - 关系数据库是一个很好的首选。

Answer 6

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

Answer 7

大约7 - 8年前，我在一个网站上工作，这个网站越来越受欢迎，超出了我们最初的期望，这让我们在性能方面遇到了麻烦。由于我们都是基于网络的项目相对缺乏经验，因此我们对于除了通常的数据库分离到单独的服务器，负载平衡等之外的事情构成了巨大的压力。

有一天，我想到了一件非常简单的事情。由于网站是基于用户的，他们的个人资料存储在数据库表中，通常的方式是有人会这样做 - 用户ID，许多信息变量和类似的东西 - 这将显示为用户个人资料页面，其他用户可以查找。我已经将所有数据刷新成一个简单的html文件，已经准备好作为用户个人资料页面并得到了显着的提升 - 基本上是一个缓存。我甚至制作了一个系统，当用户编辑他们的个人资料信息时，它会解析原始的html文件，将其编辑，然后将html刷新回文件系统 - 得到更多的提升。

我用相互发送的消息制作了一些类似的东西。基本上，只要我能使系统完全绕过数据库，避免INSERT或UPDATE，我就获得了显着的提升。这听起来像是常识，但这是一个启发性的时刻。它本身并不是关系设置的避免，但它完全避免了数据库 - KISS。