文档数据库

设想您正在处理无法整齐地放入关系型数据库的行和列中的数据。也许您正在构建一个产品目录，其中某些产品具有独特的属性（例如电视有“屏幕尺寸”而微波炉有“瓦数”），或者管理用户资料，用户可以选择提供不同的信息。将这种多变性强行纳入僵化的表结构会变得繁琐，通常需要许多空列或复杂的表关联。

这时，文档数据库提供了一种不同的方案。这些数据库中的基本存储单元不是表、行和列，而是一个文档。

可以将文档视为一个自包含的数据集合，通常以程序员熟悉的格式表示，例如 JSON (JavaScript Object Notation) 或 BSON (Binary JSON，由 MongoDB 等系统使用)。文档将相关信息聚合在一起，很像编程中的对象或复杂表单中的单个条目。

文档的结构

文档通常由字段-值对组成。字段就像标签或键，而值是相关联的数据。值可以是简单类型，如字符串、数字或布尔值，但它们也可以是更复杂的结构，如数组（列表）甚至嵌套文档（文档中的文档）。

以下是一个用户文档在 JSON 格式下的简化示例：

{
  "userId": "user123",
  "username": "alex",
  "email": "[email protected]",
  "signupDate": "2023-10-26",
  "interests": [ "hiking", "programming", "music" ],
  "address": {
    "street": "123 Main St",
    "city": "Anytown",
    "zip": "10001"
  }
}

注意，这个单一文档包含关于 'alex' 的各种信息。interests 字段保存了一个字符串列表（一个数组），而 address 字段包含另一个嵌套结构（一个嵌入式文档），拥有自己的字段。

模式灵活：主要优点

文档数据库的一个重要特点是它们的模式灵活。与关系型数据库中每行都必须符合预定义列结构不同，同一集合中的文档（一组文档，类似于表）不一定需要有完全相同的字段。

例如，同一集合中的另一个用户文档可能如下所示：

{
  "userId": "user456",
  "username": "charlie",
  "email": "[email protected]",
  "signupDate": "2023-11-15",
  "preferredContact": "email",
  "company": "Tech Corp"
}

'charlie' 的第二个文档包含 preferredContact 和 company 字段，这些字段在 'alex' 的文档中没有。反之，它缺少 interests 和 address 字段。文档数据库自然地处理这种差异，无需为所有文档预定义所有可能的字段。

对比文档集合结构与关系型表。请注意文档集合中的灵活度与关系型表中固定列（可能包含 NULL 值）的对比。

这种灵活度使得文档数据库非常适合以下场景：

• 演进中的应用： 随着应用需求的变化，您可以向新文档添加新字段，而无需修改现有文档或执行复杂的数据库模式迁移。
• 半结构化数据： 处理项目中可能具有不同属性的数据，如产品目录、用户生成内容或传感器读数。
• 存储对象： 直接存储具有复杂内部结构的应用对象。

示例与考量

流行的文档数据库示例包括 MongoDB、Couchbase 和 ArangoDB。尽管它们提供灵活度，但需要记住，这种缺乏强制结构意味着在需要时，应用程序开发人员需要承担更多管理数据一致性的责任。查询有时可能比标准 SQL 更复杂，特别是对于跨多个文档的关联（尽管文档数据库通常支持将相关数据嵌入到单个文档中以缓解此问题）。

总之，文档数据库在处理多样化、不断变化或半结构化数据时，为关系模型提供了一个强有力的替代方案，优先考虑灵活度以及与应用对象映射的便捷性，而非严格的模式强制。