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

Question

除了 google/bigtable 场景之外，什么时候不应该使用关系数据库？为什么不呢？你应该使用什么？（你学会了“艰难的方法”吗？）

Answer 1

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

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

深层层次结构和图表不能很好地转换为关系表。即使有 Oracle 等专有扩展的帮助 CONNECT BY, ，使用 SQL 来追踪树木是一件非常痛苦的事情。

关系数据库为简单的读取访问增加了大量开销。事务完整性和引用完整性非常强大，但对于某些应用程序来说却有些过头了。因此，对于以读取为主的应用程序，文件比喻就足够了。

最后，如果没有预期的意外查询，您根本不需要具有成熟查询语言的关系数据库。如果没有诉讼询问诸如“我们在东海岸按销售人员分组销售了多少 5% 折扣的蓝色小部件？”之类的问题，并且永远不会有，那么您，先生，就可以摆脱 DB 的束缚。

Answer 2

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

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

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

还有其他解决方案可以管理具有不同要求的数据。例如，语义网技术通过将元数据视为与数据一样的属性，允许每个实体定义自己的属性并进行自我描述。这比关系数据库强加的结构更灵活，但这种灵活性有其自身的成本。

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

另请参阅我的另一个答案“下一代数据库."

Answer 3

共有三个主要数据模型（C.J.Date、E.F.Codd），我向其中添加一个平面文件：

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

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

关系被认为“更好”的原因是数据检索语言和数据定义语言的声明性和标准化，包括强大的声明性数据完整性，并由 稳定的, 、可扩展、多用户管理系统。

好处是有代价的，大多数项目发现对于将长期数据存储在可预见的未来可用的系统（多应用程序）来说，这是一个很好的比率。

如果您不是构建系统，而是构建单个应用程序（可能是针对单个用户），并且您相当确定您不希望多个应用程序使用您的数据，也不希望多个用户使用您的数据，那么您可能很快就会找到更快的方法。

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

或者，如果您根本不太关心数据的完整性（这也可以）。

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

在我看来，关系模型有多好的一个例子是涉及 SQL 的问题的复杂性与简短性的比率。

Answer 4

我建议您访问高可扩展性博客，讨论几乎每天这个话题，有关于多篇那些选择分布式哈希等过RDMBS项目。

在快速（但非常不完整的答案）是不是所有的数据转换以及以有效的方式表。例如，如果你的数据基本上是一个大辞典，有可能更快速的替代品普通的老RDBMS。话虽如此，它主要表现的问题，如果性能是不是在一个项目一个巨大的关注和稳定性，一致性和可靠性，例如，是的话，我看不出有任何点在深入研究这些技术时， RDBMS是一个更加成熟和发达的方案，在所有的语言和平台和庞大的一整套解决方案的支持，以供选择。

Answer 5

15年前，我正在一个信用风险系统（基本上是一棵大树步行系统）上。我们对HP-UX和Solaris上使用Sybase和performnce被杀死我们。我们聘请了从Sybase顾问直接说谁也不能做到。然后，我们切换到OO数据库（在这种情况下，对象存储）并获得了约100倍的性能提升（和代码为约100倍更容易编写过）

但是，这种情况是相当少见的。 - 一个关系数据库是一个很好的第一选择

Answer 6

在架构变化很大，你将有一个艰难的时间与关系型数据库。这是XML数据库或键值对数据库的效果最好。或者可以使用IBM DB2和具有由一个单一的数据库引擎管理二者关系数据和XML数据。

Answer 7

约7-8年前，我曾在一个网站逐渐普及超出了我们最初的预期，并陷入困境的性能代价了我们。由于我们在基于Web的项目都相对缺乏经验造成它什么超出平常数据库分离办在单独的服务器，负载均衡等对我们有显著应变

有一天我想过的东西很简单。由于网站是基于用户，他们的个人资料被存储在一个数据库表中的常用方法会有人做到这一点 - 用户ID，大量的信息变量和类似的东西 - 这会显示为一个用户的个人资料页其他用户可以查找。我已经刷新所有的数据到一个简单的HTML文件，已经准备为用户的个人资料页，并得到了显著提升 - 基本上是一个缓存。我还送了一个系统，当用户编辑自己的个人资料信息，它会分析原始的HTML文件，把它进行编辑，然后冲洗掉HTML回文件系统 - 得到更加提升。

我做了一些呈三角与发送给对方邮件的用户。基本上，无论我可以做一个系统完全绕过数据库，避免了INSERT或UPDATE，我有显著提升。这听起来像一个常识，但它是一个启发性的时刻。它本身并不关系建立的回避，但它是数据库的完全回避 - KISS。