如果您曾经盯着 Firestore 控制台想「我把那个数据放哪了？」或「为什么这个查询不起作用？」,您并不孤单。Firestore 很强大,但它的 NoSQL 本质让大多数开发者感到困惑 — 尤其是那些来自 SQL 数据库的开发者。让我们详细分析为什么它令人困惑以及您可以采取什么措施。

为什么 Firestore 感觉如此不同

如果您使用过 MySQL、PostgreSQL 或任何 SQL 数据库,您已经训练了大脑以表、行和连接来思考。Firestore 将所有这些都抛诸脑后。没有表 — 只有集合。没有行 — 只有文档。没有连接 — 只有反规范化的数据。而且没有 Schema 强制执行 — 同一集合中的文档可以具有完全不同的字段。

思维模型转变：

SQL

具有固定列的表 → 行遵循严格的 Schema → JOIN 组合相关数据 → 规范化避免重复

Firestore

具有灵活文档的集合 → 每个文档可能不同 → 没有 JOIN — 改为反规范化 → 重复是预期的并且受到鼓励

每个 Firestore 初学者都会犯的 5 个错误

1. 试图规范化所有内容

在 SQL 中,您规范化以避免数据重复。在 Firestore 中,这会强制您进行多次读取以组装单个视图。相反,将数据存储在您读取它的地方 — 即使这意味着在用户编写的每条评论中复制用户的显示名称。

2. 使用数组存储关系

在文档中存储用户 ID 数组似乎合乎逻辑,但 Firestore 数组有严重限制：您无法高效查询单个元素,并且它们超过几千个项后无法扩展。改用子集合或带引用的单独集合。

3. 将所有内容放入一个文档

Firestore 按文档读取收费,因此很容易将所有内容塞进一个大文档。但文档有 1 MB 的限制,当您只需要 2 个字段时读取 500 KB 的文档会浪费带宽并增加成本。拆分为专注、较小的文档。

4. 预先忽略查询限制

Firestore 无法在单个查询中对多个字段进行不等式过滤,无法进行本地全文搜索,并且需要复合查询的索引。从第一天开始围绕您的查询设计数据模型 — 而不是反过来。

5. 不记录结构

没有 Schema,您的 Firestore 数据库就变成了一个黑盒。新团队成员猜测字段名称、拼写错误导致静默 Bug,没有人知道字段是必填还是可选。这是最常见且最具破坏性的错误。

如何为 Firestore 数据库带来结构

好消息：您可以在不放弃灵活性的情况下为 Firestore 添加结构。以下是三个实际步骤：

1首先设计查询

在创建集合之前,列出应用程序中的每个屏幕及其需要的数据。这种查询优先的方法确保数据模型为 UI 服务 — 与 SQL 思维相反,后者先设计表。

2使用一致的字段名称和类型

尽早决定约定：camelCase 还是 snake_case？时间戳是 Firestore Timestamp 还是 ISO 字符串？必填字段与可选字段？将这些决定写在团队可以找到的地方。

3使用 JSON Schema 记录集合

JSON Schema 是一个开放标准,可让您描述每个集合的结构：字段名称、类型、哪些是必填的、什么值有效。它就像数据库的蓝图 — 如果您将其保存在代码仓库中,它还可以作为保持准确的文档。

在实践中是什么样子

这是一个描述 Firestore users 集合的简单 JSON Schema。请注意每个字段都有类型和描述 — 团队中的任何人都可以一目了然地理解数据模型：

schemas/users.schema.jsonJSON

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "collection": "users",
  "description": "Registered app users",
  "schema": {
    "type": "object",
    "properties": {
      "displayName": {
        "type": "string",
        "description": "User's full name"
      },
      "email": {
        "type": "string",
        "format": "email",
        "description": "Login email address"
      },
      "role": {
        "type": "string",
        "enum": ["admin", "editor", "viewer"],
        "description": "Access control role"
      },
      "createdAt": {
        "type": "string",
        "format": "date-time",
        "description": "Account creation timestamp"
      }
    },
    "required": ["displayName", "email", "role", "createdAt"]
  }
}

这个 Schema 文件存在于您的代码仓库中,在 PR 中被审查,并作为 users 集合的唯一权威数据源。不再需要猜测。

将 Schema 转化为交互式文档

一旦您为集合拥有 Schema 文件,像 FireSchema 这样的工具就可以将它们渲染为交互式可浏览文档 — 类似于 Swagger UI 对 REST API 的作用,但专为 NoSQL 数据库设计。它是免费的、开源的,设置大约需要 5 分钟。

下一步

继续构建您的 Firestore 知识：

为什么 Firestore 令人困惑（以及如何解决）