在“面向前端开发人员的数据库”系列的第 1 部分“无服务器数据库的兴起”中，我们讨论了扩展和维护数据库的障碍和陷阱。今天我们和大家分享一下
网站建设如何选择更合适的服务器，从更简单、更专业的替代方案（如内容管理系统和电子表格）转向自托管数据库，最后转向无服务器数据库。
我们将探索概念，让您对哪种数据库适合您的特定需求有自己的看法。提前强调这一点很重要：没有正确的答案。每个数据库都有自己的权衡和优势。如果某些东西看起来像“一刀切”的解决方案。在开始之前，重要的是要强调我们松散地称为“数据库”实际上是“数据库管理系统 (DBMS) ”。DBMS 是一种软件，它使用户能够更符合人体工程学地写入、读取、删除或更新给定数据集中的信息。对于本系列，我们将主要关注关系和非关系 DBMS。还有许多其他类型，都按其数据结构分类，但关系型和非关系型是 Web 开发最常见的类型。
关系 (R)和非关系 (NR) DBMS对组成它们的部分都有不同的术语。这些组件在定义上几乎可以互换，这就是为什么您通常会听到开发人员将文档（NR 术语）称为“表”，这是它的关系等价结构。不要害怕混淆它们；它们经常出现，足以让这种认知超载随着使用而迅速消失。此外，一旦您更熟悉每种数据结构的差异，您就会意识到它们可能不应该互换使用，因为它们之间存在差异。但是现在，为了简单起见，让我们关注相似之处。
一旦您查看了不同的数据结构并选择了您的 DBMS，您就可以绘制从数据层到应用程序层的第一个连接。突然间，您注意到将数据从数据库带到客户端（在某些情况下甚至是服务器端 API）并不是那么简单。这里有 ORM（对象关系映射）和 ODM（对象文档映射）来帮助您的开发体验。Prisma可能是目前使用最广泛的 ORM，而Mongoose拥有最大的 ODM 用户群。重要的是要注意它们不是连接到数据库的要求。尽管如此，如果您密切关注它们如何构建您的查询（某些特定情况可能会因抽象而出现性能问题），它们往往会使您的生活更轻松，并且获取或写入数据更符合人体工程学。
当谈到无服务器数据库时，对它们的需求变得更加可疑。这是因为这些数据库中的许多都为用户提供了官方支持的软件开发工具包 (SDK)。您的里程会因 SDK 而异，但它们往往与 ORM 和 ODM 有很大的功能重叠，尤其是在将数据层保持在 API 之后的数据库上（例如Xata）。这样，您就无需担心翻译查询，并且您可以要求 SDK 和 ORM 之间的等效人体工程学。
在我们系列的这一部分中，我们正在学习为我们的数据层选择堆栈时要寻找什么。了解有关维护和选择 DBMS 的常见概念至关重要（从现在开始，我们重新将它们称为“数据库”以与世界其他地方保持一致）。接下来的部分不会深入到您跳出并找到一份数据库管理员 (DBA) 的工作，但希望它会为您提供足够的弹药来与专家进行对话并为您的用例确定最佳解决方案。这些概念对于每一种数据层都很常见，从电子表格到自托管数据库，甚至到无服务器数据库。不同的是每个解决方案将如何平衡这些范式中交织在一起的变量。
首先，最重要的概念是一致性、可用性和分区容错性。如果将它们一起呈现，它们会更好地理解，因为它们之间的平衡将指导您的数据在不同上下文中的可预测性。该定理描述了分布式系统中 3 个组件之间的关系：一致性、可用性和分区容限 (CAP)。总体结论很容易总结：任何系统都只能同时考虑其中的两个组件。虽然只是一个简单的句子，但这个想法需要一些解包。在 CAP 定理约束中，“一致性”直接指数据。当不同的客户端发出相同的请求时，它们将得到相同的响应。当书面请求被接受并确认后，所有用户将同时访问此更新信息。每个请求都会收到带有数据的响应。没有错误。但是，这并没有承诺数据是否是最新的。根据这是否与一致性 © 或分区容差 (P) 配对，您将获得不同的行为。
有了这个，我相信我们已经准备好开始缩小我们对每种数据库类型之间差异的讨论。此外，可以讨论和评估对所采用的每个解决方案的期望，并单独分析架构。从现在开始，我们将专注于关系和非关系数据库。
