73

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

4

7 回答 7

41

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

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

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

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

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

于 2009-03-20T19:41:21.667 回答
22

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

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

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

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

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

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

于 2009-03-20T18:21:21.657 回答
13

有三个主要数据模型（CJDate、EFCodd），我正在向其中添加一个平面文件：

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

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

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

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

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

此外，如果您不知道要存储什么样的数据以及如何对其建模，那么关系模型的优势就会被浪费在上面。

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

所有数据结构都针对某种用途进行了优化，只有在适当建模的情况下才会尝试以语义无偏见的方式表示“现实”。对关系数据库体验不佳的人通常不会意识到他们使用其他类型的数据模型的体验会更糟。可怕的实现是可能的，尤其是关系数据库，在其中构建复杂的模型相对容易，你最终可能会得到一个相当大的怪物。当我尝试在 xml 中想象同一个怪物时，我总是感觉更好。

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

于 2010-03-23T00:33:11.360 回答
12

我建议您访问High Scalability 博客，该博客几乎每天都在讨论这个主题，并且有许多关于选择分布式哈希等项目而不是 RDMBS 的文章。

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

于 2009-03-20T17:31:11.260 回答
9

十五年前，我正在研究信用风险系统（基本上是一个大树行走系统）。我们在 HPUX 和 solaris 上使用 Sybase，性能让我们感到很沮丧。我们直接从 Sybase 聘请了顾问，他们说无法做到。然后我们切换到 OO 数据库（在本例中为对象存储）并获得了大约 100 倍的性能提升（并且代码也更容易编写 100 倍）

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

于 2009-03-20T17:31:15.647 回答
8

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

于 2009-03-20T20:37:07.587 回答
3

大约 7 到 8 年前，我在一个网站上工作，该网站的受欢迎程度超出了我们最初的预期，这让我们在性能方面遇到了麻烦。由于我们在基于 Web 的项目方面都相对缺乏经验，这给我们带来了很大的压力，除了通常的数据库分离到单独的服务器、负载平衡等之外，我们还需要做什么。

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

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

于 2009-03-20T19:50:48.290 回答