SQL和关系数据库详解（非开发人员撰写）

欢迎来到“非开发者解读开发者术语”系列的第二期。像JavaScript这样在现代开发中应用广泛且复杂的术语，该如何解释呢？我决定回归软件开发中一个更成熟可靠的功能——SQL。

SQL 代表结构化查询语言，用于在关系数据库中进行通信和操作。它擅长处理结构化数据，包括实体之间的关系以及这些实体的变量。

另一堂简史课

SQL 语言的历史相当悠久，最早可以追溯到20 世纪 70 年代。当时，IBM 的研究人员根据 Edgar Frank Todd 的论文《大型共享数据库的关系模型》中的研究成果，创建了一种最初名为 SEQUEL 的查询语言。没错，就像 JavaScript 一样，SQL 也曾有过另一个名字。不过，与 JavaScript 更名不同的是，SQL 更名是由于商标侵权，并没有什么隐晦的营销手段。这次更名大约发生在 1973 年，但我没能找到确切的日期。尽管名称已经更改，但时至今日，关于 SQL 的发音仍然存在争议，有人读作“SQL”，有人读作“sequel”。那么，SQL 到底该怎么读呢？

SQL逐渐成为关系数据库管理系统（RDBMS）的通用标准，至今仍是数据库领域的重要参与者，但直到1979年才真正面向公众开放。当时，一家名为Relational Software的公司发布了其商业版SQL，名为Oracle V2。如果您还没猜到，Relational Software后来发展成为Oracle。SQL商业化之后，MySQL等产品应运而生，满足了企业无需耗费时间管理数据库或从头编写SQL的需求。时至今日，MySQL仍然是最流行的SQL数据库管理系统之一，并为所有现有的数据库管理系统树立了标准。

选择 SQL 还是 NoSQL，这才是关键问题

啊，这个问题。只要对数据库稍有了解，每个人都听过、讨论过、辩论过这个问题。首先，我要分享一篇我最喜欢的博客文章，它比较了 SQL 和 NoSQL，作者是 HarperDB 的首席技术官 Kyle。他出色地解释了两者的区别，以及 HarperDB 的定位（我们有点特立独行🙂，这是好事）。此外，我的同事 Margo 也写了一篇关于不同数据库架构的精彩文章。

所以，当我学习 SQL 和 NoSQL 时，我的第一个问题是：如果 SQL 这么好，为什么我们还需要 NoSQL 呢？嗯，就像世间万物一样，SQL 也有其局限性。关系型数据库通常在垂直方向上比水平方向上更容易扩展。我说的水平和垂直扩展到底是什么意思呢？这本身就可以写一篇完整的博客文章了，所以我在这里分享一个很棒的资源，它总结了可扩展性以及双向扩展的含义。请记住，可扩展性“是指系统、网络或进程处理不断增长的工作量的能力，或者说是其扩展以适应这种增长的潜力。”

SQL功能强大，可以处理各种类型的数据。它能够应对上世纪七八九十年代的数据量。随着世界的发展和新技术的涌现，我们开始面对海量的数据。数据集不断增长，尤其是在物联网和边缘计算兴起的今天，数据量仍在持续增长。关系型数据库已经无法满足需求，而SQL本身的结构化特性，以及它需要预先定义数据模式，更是雪上加霜。而这正是NoSQL的用武之地。

大型数据通常是非结构化的，可以是推文、电子邮件、图像和文档，也可以是视频和音频文件。对于 SQL 和关系型数据库管理系统 (RDBMS) 而言，“关系型”字面意思是数据是相关的而非随机的，这类数据库通常是表格型的，因此它们本质上并非为非结构化数据而设计。（不过，如今一些关系型数据库已经内置了处理此类问题的功能）。更不用说规模问题了！正如 Kyle 在他的博客中所述，关系型数据库可以垂直扩展，但这存在局限性，通常意味着需要迁移到更大的服务器。这个过程可能成本高昂、繁琐，而且说实话令人担忧，因为很多环节都可能出错，而在 2020 年，数据就是黄金，丢失数据后果不堪设想。NoSQL 的意思嘛，就是没有结构或无模式，这意味着你可以直接把数据放进去，无需任何结构。你可能还会听到“动态模式”这个术语，它指的是数据结构会随着新数据的导入而动态变化。

可以把 NoSQL 的结构想象成一个桶，你可以把数据直接倒进去，数据仍然可以被排序和交互；而 SQL 就像一个书架，你需要仔细规划如何对数据进行分类。

其他主要区别在于 SQL 基于表，而 NoSQL 基于键值或文档，这两点都与结构化和非结构化的概念相关。你可以把 NoSQL 的结构想象成一个桶，你可以把数据直接倒进去，数据仍然可以排序和交互；而 SQL 则像一个书架，你需要精心规划如何对数据进行分类。把数据倒进桶里更快更容易，而且这个桶没有书架的“墙壁”限制，可以容纳更多的数据，但快速找到所需数据就比较困难。书架的优点在于它能把所有东西都整齐有序地存放起来，但如果一条数据可能需要放在两个不同的“架子”上，或者必须同时出现在两个“架子”上呢？

你最喜欢 SQL 数据库的哪一点？NoSQL 呢？请在评论区告诉我！这里还有一篇很棒的文章，他们把 SQL 和 NoSQL 的区别分析得非常透彻。

SQL 将继续存在：NewSQL

许多数据库都声称自己是 NewSQL，因为对某些人来说，NewSQL 似乎是一个热门的新词。在我看来，它确实是一个有效的数据库类别，但如何将数据库归入 NewSQL 范畴却存在一些混乱。正如我们 HarperDB 的一位联合创始人最近在他关于 NewSQL 的博客文章中所写的那样：

当我们审视“NewSQL”数据库的定义时，会发现以下几个关键点：

• “……一类旨在提供 NoSQL 系统可扩展性的关系数据库管理系统……”
• “……同时保持ACID 的各项保证……”
• “许多企业系统……对于传统的关系型数据库来说规模太大，但……对于 NoSQL 系统来说又不实用。”
• “这些机构之前唯一的选择就是购买更强大的计算机。”
• “……或者开发定制中间件……”
• “这两种方法都存在基础设施成本和/或开发成本高昂的问题。NewSQL系统试图调和这些冲突。”

我们最初创立 HarperDB 时，曾讨论过它同时具备 SQL 和 NoSQL 功能，当时我们以为大家会立刻明白这有多棒……但事实并非如此。他们的反应往往是：“那又怎样？” 这是因为 NewSQL 当时还是个比较新的术语，定义也不够明确。人们误以为像 MongoDB 这样的数据库同时具备这两种功能，因为它们提供了类似 SQL 的东西。虽然它并非真正的 SQL，但对大多数人来说，这意味着它们可以同时使用这两种功能。（像 MongoDB 这样的工具实际上集成了复杂的组件来尝试实现 SQL 功能，而HarperDB 则在一个简单的工具中开箱即用。）因此，NewSQL 才是 NoSQL 和 SQL 的真正融合。如今数据变得极其复杂，海量数据来自数百万个数据源。NewSQL 正是应对我们这个日益数据驱动的世界的答案。

NewSQL 将会持续发展壮大，并成为众多应用场景的理想选择。首先，它非常适合那些尚未被复杂架构的传统系统束缚、耗费巨资的初创公司和新兴企业。从事业余项目的个人开发者也可能选择 NewSQL。另一个例子是，对于那些需要符合 ACID 标准的传统 SQL（而非 NoSQL 数据库常用的 BASE 标准）且对高性能和可扩展性有更高要求，同时又希望成本低于传统 RDBMS 系统（构建于服务器之上）的应用场景。NoSQL 数据库用户也可能希望在保持 NoSQL 所具备的性能和可扩展性的同时，实现符合 ACID 标准的 SQL。甚至一些编程学校也在考虑使用 NewSQL 产品，以便通过单一工具轻松地让学生接触 SQL 和 NoSQL。

总结

总之，随着世界的发展和我们技术的不断进步，我们的数据也在随之演进。SQL永远不会消失，毕竟它是第一个被普遍认可的数据库语言。NoSQL和SQL数据库都非常庞大，主要体现在它们的结构、可扩展性和性能等方面。它们在2020年都扮演着重要的角色，并且在未来对企业或项目的运营仍然至关重要。NewSQL是针对一个在20世纪80年代并不真正存在的问题而提出的现代解决方案，但如今，对于许多企业和初创公司来说，如何“兼顾两者的优势”可以说是最大的挑战。您对NewSQL有什么看法？我肯定遗漏了SQL和NoSQL之间的一些其他区别，欢迎在评论区分享您的见解！