在
网站建设行业中，作为前端开发人员，我们了解数据在我们日常工作中所扮演的基础角色。它可能来自外部 API、CMS 甚至电子表格。随着无服务器数据库日益流行，创建具有垂直和水平扩展、高可用性和防弹一致性的全栈架构从未如此简单。
要充分利用这种架构的好处，了解为您做出的决定至关重要。就像“学习 JavaScript，而不是框架”的口号流行起来一样，我们也应该了解数据库架构背后的概念，以便可靠地使用它们。本文不会让您成为分布式系统专家或有能力担任数据库管理员角色，但它将阐明您在准备选择下一个堆栈时将面临的概念、术语和首字母缩略词。将其视为（无服务器）数据库的入门。
用户界面（你和我，或 U 和我，或 UI）与数据库的界面非常相似。电子表格为您提供了一个用于存储数据的表格。在某些情况下，它们只允许您为每列定义特定的数据类型。熟悉的地方就在那里，但是一旦我们打开引擎盖，电子表格就会突然结束。可用性是有问题的：电子表格不是用来提供内容的，只是用来存储内容的。对于初学者来说，它们不会随着应用程序的扩展而为应用程序提供动力，而且在确保数据完整性方面，它们可能不遵守某些最佳实践。直到最近，它们都是开始使用某些数据层的最快方式。但是现在，应用程序不使用真实的（无服务器）数据库是没有意义的（稍后会详细介绍）。
内容管理系统 (CMS)是另一种数据库。“内容”是 CMS 专门研究的一种特殊类型的数据。它将为用户（开发人员）提供足够的抽象，以促进将此类数据管理到不关心底层数据库的程度。它将处理数据的可交付性、可用性和完整性。但是抽象越重，权衡就越大。数据类型仅限于 CMS 将提供给您的数据类型，大多数甚至强加自己的体系结构来处理关系、查询、类型等。当然，CMS 仍然有重要且可行的用例，而且它们不会出现任何地方。因此，只要您确定这是您的用例，您就可以使用一个。
如果您选择更简单、“抽象”的电子表格或 CMS 路线作为您的事实来源，并且您的数据开始多样化，那么障碍就会出现。电子表格的第一个问题通常与底层 API 有关，它通常不适用于大多数平均大小的应用程序的流量，然后是第一个重构对话。
使用 CMS，API 通常不是问题，但管理数据可以。随着应用程序的增长和数据的多样化，其中一些最终不再是内容，并且可能与应用程序逻辑更相关。当数据不是内容时，在 CMS 中管理数据并不理想。它不太灵活，通常不适合所有者团队的工作流程。现在，虽然其他数据库和 CMS 完全有可能共存，但开发人员需要了解每种解决方案的优缺点，并决定什么最适合他们的应用程序交付和用户体验。
