MongoDB

是什麼

不妨想像一疊索引卡，每張卡可以記錄不同的欄位，而不是一張每行都必須有相同列的固定表格。MongoDB 的工作方式就像這疊卡片。它是一個文件資料庫，將資料儲存為靈活的文件（可以把每個"文件"想成一張卡片），並按集合分組。這些文件以一種叫 BSON 的格式儲存，它是 MongoDB 把（JavaScript 物件表示法，一種用具名欄位書寫資料的常見方式）轉成的二進位制形式。它沒有剛性的表和行，每個文件可以有自己的結構，這使得快速演進資料模型變得容易。對於資料天然對映為巢狀物件的應用，它是一個流行的選擇。

優勢

靈活的模式：文件可以各不相同並隨時演進，無需遷移。
資料直接對映到應用物件，減少了轉換程式碼。
豐富的查詢語言，外加強大的聚合管道。
通過內建分片實現水平擴充套件。
對巢狀欄位和陣列欄位提供強力支援。

取捨

若缺乏嚴謹的模式設計，很容易產生不一致的資料。
多文件事務雖然存在，但比關係型儲存更為沉重。
連線（$lookup）相比（結構化查詢語言）較為受限；資料通常需要反規範化。
反規範化（為減少查詢而把同一份資料的副本存放在多個地方）會重複儲存資料，並使更新變得複雜。

何時使用

對於內容管理、商品目錄、使用者資料、事件日誌，以及資料不斷演進或具有層級結構、文件比規範化表更合適的應用，可以選擇 MongoDB。

與 vibe coding 的契合度

在指揮 AI 時，不要讓"無模式"變成"無規劃"。讓 AI 定義清晰的文件結構，並用 JSON Schema 校驗或 Mongoose 這類 ODM（物件-文件對映器）來強制執行，包括必填欄位和型別。根據訪問模式告訴它是該內嵌相關資料，還是通過 id 引用，併為你查詢和排序所用的欄位新增索引。一個好建議：讓 AI 使用引數化的查詢物件，也就是絕不要把使用者輸入的原始字串拼接成查詢。還要讓它解釋自己在內嵌與引用之間的取捨。這樣你就能理解讀寫和更新的成本。

// 模式校驗讓文件保持一致
db.createCollection("users", {
  validator: {
    $jsonSchema: {
      bsonType: "object",
      required: ["email", "createdAt"],
      properties: {
        email:     { bsonType: "string" },
        createdAt: { bsonType: "date" },
        roles:     { bsonType: "array", items: { bsonType: "string" } }
      }
    }
  }
});

db.users.createIndex({ email: 1 }, { unique: true });

// 聚合：按角色統計活躍使用者數
db.users.aggregate([
  { $match: { active: true } },
  { $unwind: "$roles" },
  { $group: { _id: "$roles", count: { $sum: 1 } } }
]);