简介
随着时间的推移，数据库的设计旨在适应许多不同的使用模式、组织层次结构和一致性约束。其中两个最持久的设计是关系型数据库和文档数据库。
在本指南中，我们将了解这两种数据库模型，以更好地了解它们的相对优势和劣势，并评估它们最适合的应用场景。我们将了解它们如何处理数据结构、查询以及在项目中使用它们的影响。
关系型数据库和文档数据库如何组织数据
关系型数据库与文档数据库的核心区别在于它们采用的实际数据库模型。数据在管理系统中存储和组织的方式对它们允许的操作类型、哪些访问模式性能最佳以及与应用程序逻辑集成的难易程度具有广泛的影响。
关系型数据库如何构建数据
关系型数据库的数据结构主要通过相关的机制层次结构来定义：数据库、表和列。
数据库本身充当系统中各种表和属性的容器。数据库层允许管理员将策略和属性全局应用于相关数据集。它们还充当命名空间，以限制表和其他子元素发生命名冲突的可能性。
在这些数据库中，数据的结构由表定义。表是通过声明一组列的名称和属性并配置表范围的属性来创建的。
每列都指定一个数据类型，该数据类型控制可以存储在其中的数据形状。约束也可以在列和表上声明，这允许您对字段的有效数据施加额外的要求。数据本身作为表中的行存储。每个记录为表的每一列存储一个值。
总而言之，关系型数据库管理系统 (RDMS)将相关的表和设置分组到数据库中。每个表通过设置一系列具有数据类型和其他属性的列来定义它可以保存的记录的特定结构。记录作为行添加到表中，每行记录表每一列的值。
文档数据库如何构建数据
文档数据库管理系统也通过相关组件的层次结构来构建其数据，但使用了一组不同的范例。文档数据库通常使用数据库、集合和文档的系统。
与关系型数据库一样，文档数据库系统使用一个总体的“数据库”抽象来封装相关数据，以便实现全局策略和命名空间划分。数据库层充当容器，用于定义广泛的属性、允许有凝聚力的访问控制以及将操作范围限定到相关上下文中。
在数据库中，一个名为集合的分组用于将各个文档捆绑在一起。集合的定义比表（其关系对应物）更宽松，主要用作容器和额外的范围限定机制。
与关系型数据库不同，集合本身不定义它们可以存储的文档的字段或属性。相反，每个文档的结构由它声明的字段和数据隐式定义。由于结构是各个文档的属性，而不是集合的属性，因此集合中文档的形状可能会有很大差异。遵循可理解的结构是数据库用户的责任，而不是数据库系统本身强制执行的属性。
结构和灵活性之间的相互作用
鉴于这两种设计采用的不同数据管理理念，令人惊讶的是，在为用户提供的结构和灵活性方面存在一些主要差异。一般来说，关系型数据库系统倾向于优先考虑结构、可预测性和一致性，而文档数据库更喜欢灵活性、响应性和适应性。
结构刚性的理由
通过使用表，关系型数据库预先配置其数据的形状。存储在表中的每个记录都必须符合表实现的结构，没有例外。
要更改数据的结构，必须更改表结构本身，并且需要更新任何现有记录以匹配新结构。这种系统使得结构更改相对昂贵，因为表中已输入的每条数据都需要更新。这可能意味着更新表中的每个记录、重建索引以及必须决定回填最初输入时未记录的值的最佳方法。
这种成本使得提前仔细考虑数据结构是明智的，这可能会让人感到畏惧。但是，重要的是要记住，这种方法在数据完整性方面提供了大量的保证和安全性。
存储在表中的数据将始终是同质的，达到表定义要求的程度。这是一种强制执行机制，可以帮助您维护井井有条的数据，无需检查每个数据项的各个属性即可对其进行推理。
表结构提供了关于您数据的保证，如果没有关于数据应如何呈现的共识，这是不可能的。这可以帮助您避免在数据一致性和连贯性方面出现整类问题，尤其是在随着与数据库接口的应用程序逻辑发展的情况下。
灵活性的理由
另一方面，文档数据库分别定义每个文档的结构。结构是文档本身定义的特征，而不是记录必须符合的外部结构。
这在许多不同的领域为您提供了极大的灵活性。您可以动态更改要记录的各个记录的数据，延迟或跳过回填以前保存的文档，或者在同一集合中存储结构非常不同的文档，而无需在每个其他文档中将缺失值设置为 NULL。
在您开发时，您的数据库结构可以与您的应用程序逻辑一起轻松演变。这使得更改不那么繁琐，因为与每次结构更改相关的同步和迁移过程较少。数据库系统将允许您要应用的所有新文档结构与所有以前的结构一起存在。如果您需要调整现有记录，您可以回填数据或将结构带外修改为单独的过程。
文档模型提供的灵活性鼓励您存储逻辑的迭代和演变。但是，重要的是要记住，软件本身不太可能为您提供与您进行更改时一样多的关于数据的保证。如果没有关于数据集合形状的约定标准，那么作为开发人员，您有责任强制执行一致性，并在适当的时候修改文档以使您的数据保持在良好理解的状态。
规范化、连接和数据共存
关系型数据库模型最有用的功能之一是连接的概念。连接是允许您将不同表中保存的数据拼接在一起的查询，以便您可以将它们作为一个单元进行处理。虽然从效率、逻辑或一致性的角度来看，将某些数据片段存储在不同的表中可能是有意义的，但通常您会希望检索数据或以其他方式跨越这些边界进行操作。
规范化是一种表设计理念，它鼓励您以一种保证跨表边界数据一致性的方式组织数据。规范化在某些方面是连接的要求，同时也是关系模型中需要连接的主要原因之一。
您可以将规范化视为一种通过根据数据离散部分的可重用程度逻辑地分离数据来维护数据一致性的策略。例如，表示唯一客户的记录与表示客户的单个订单之一的记录的使用方式非常不同。规范化鼓励您将这些类型的信息分离到它们自己的表中，而连接为您提供了在需要时组合它们所需的机制。
连接需要结构一致的数据，其中字段可以相互映射以匹配各个记录。由于文档模型不强制记录的固定结构，因此在该范例中构思连接是一个更困难的操作。话虽如此，但重要的是要注意
- 类似的功能可以在许多文档数据库系统中实现
- 该模型本身鼓励较少分散的数据存储
这在实践中意味着文档结构没有像关系型数据库那样推动规范化的压力。记录可以并且经常包含嵌套信息，这些信息通常在关系模型中是分开的，允许您在单个文档中检索相关信息，而不是将多个实体拼接在一起。即便如此，聚合运算符可以使用与关系型数据库相同的一些方法在文档模型中提供与连接相同的一些基本功能。
查询数据
关系型数据库传统上倾向于实现结构化查询语言或 SQL 作为其主要查询语言。SQL 可用于查询现有数据、插入新数据、创建或修改数据库结构以及管理通用数据库环境。SQL 自 1970 年代就已出现，有许多不同的迭代和实现，并且通常被认为是遵循基于表的结构的数据库的标准接口。
SQL 有许多支持者和反对者，并且可能是一个两极分化的话题，部分原因是其悠久的历史、不一致的标准以及与传统编程语言相比不同的工效学。SQL 在它可以访问和检索的内容方面相当富有表现力和灵活性，但以编程方式处理它可能很麻烦，因为它的语法和语句结构可能难以解析和构造。此外，它不遵循许多其他语言 laid out 的模式，因为正如其名称所示，它的构想主要是作为一种命令和查询语言，而不是一种用于数据编程的通用语言。
对于关系型数据库，SQL 通常是与数据库系统交互的主要手段。对于文档数据库，记录结构与 SQL 中固有的假设不一致，因此需要新的查询语言来与系统交互以及输入、查询和修改数据。有些语言从 SQL 中汲取了大量灵感，而另一些语言则实现了全新的语言，试图摆脱 SQL 中一些更令人沮丧的缺点。
在许多文档数据库中，查询语言的设计旨在遵循应用程序开发人员可能更熟悉的访问模式。它们通常实现一个类似 API 的接口，该接口模拟开发人员用于 JSON 类数据管理的工具，以便他们可以重用现有模式。虽然关系型数据库倾向于围绕 SQL 标准收敛，但文档数据库和其他 NoSQL 数据库可能彼此具有非常不同的接口。通常，与实际数据库一起开发的查询语言是不同文档数据库解决方案之间差异化的点之一。
扩展到单个数据库之外
大多数传统关系型数据库最初是在假定基础设施环境相当简单的时代设计的。在许多情况下，垂直扩展，或通过向单个主机添加额外资源来扩展数据库的性能，是最简单的策略，并且通常可以满足任何新的需求。
水平扩展也是可能的，可以通过将数据库复制到多个追随者或通过分片数据来实现：在多个主机之间拆分数据库，以便每个主机负责完整数据的子集。这些策略允许在仅仅管理单个主机的资源之外具有一定的灵活性，并且还提供了额外的优势，例如提高可用性和故障缓解。
但是，关系型数据库可以轻松地跨多个主机扩展的方式存在限制。对数据一致性的关注意味着写入操作尤其难以在主机之间实现，因为必须有一种方法就应用于数据集的更改达成共识。对此的典型解决方案是将所有写入操作转发到单个主机，或者在多个主机之间协调昂贵的共识算法，这通常对吞吐量和性能产生巨大影响。
已经开发出更新的关系型数据库来帮助解决这些问题，因此该领域取得了重大进展。但是，某些扩展困难是关系模型本身固有的。当跨大部分数据设置约束和一致性要求时，必须存在某种级别的协调开销来管理跨各种主机的状态数据。在某些重要方面，关系模型似乎需要集中的管理架构。
另一方面，文档数据库能够避免许多这些缺点，这归因于它们在系统中构建数据的方式。通过将相关数据共置在单个文档中，可以最大限度地减少不同主机之间的协调。分片数据集是文档数据库中更常见的策略。这是因为基于文档的操作通常不需要太多协调，因为许多操作都针对单个记录。
由于文档数据库中各个文档和集合之间存在的约束和链接较少，因此协调通常更容易，并且操作往往更独立。这使得文档数据库提供商能够优先考虑性能和可用性，而关系型数据库通常被迫以一致性为代价做出让步。这种权衡可能会对数据的安全性以及系统处理中断和网络分区的能力产生许多影响。最终的主要区别在于，文档数据库在调整一致性与性能和可用性的级别方面往往具有更大的灵活性，而关系型数据库通常要求一致性始终是首要任务。
结论
在某些方面，关系型数据库和文档数据库在组织数据并使其可管理和可访问方面的方法截然不同。它们的基本设计对它们适用的应用程序类型以及在与它们一起工作时可能遇到的挑战具有深远的影响。
虽然关系型数据库和文档数据库都可以在某些场景中使用，但您的项目的优先级和开发实践通常更符合其中一个系统。在可能的情况下仔细评估这两个选项是值得的，以了解您可能做出的权衡以及哪个系统提供了您真正重视的功能。
如果您正在使用 Prisma 来管理您的 MongoDB 数据库，您需要在您的 Prisma 模式文件 中的 'datasource' 代码块中设置连接 URI。您必须为 'url' 字段提供连接 URI 示例，以便 Prisma 可以连接到您的数据库。
