0Pricing
MongoDB Academy · 课时

集合与 SQL 表的比较

您将对比 MongoDB 集合与关系型数据表，并理解灵活模式如何改变数据设计。

集合与 SQL 表的比较 是 CoddyKit 上的免费 MongoDB Academy 课时。 这是第 2 节课，共 4 节。 你可以在下方免费阅读本课时的完整内容 — 然后在浏览器中使用内置代码编辑器和全天候 AI 导师进行实践。 这是 MongoDB Academy 学习路径的一部分，你的进度在网页和 CoddyKit 应用中同步。 MongoDB Academy 课程共包含 4 节课。

本课时的部分内容尚未翻译，以英文显示。

Tables vs Collections at a Glance

SQL's basic unit is the table, where every row has identical columns. MongoDB's is the collection — a group of documents that can each differ.

Fixed Schema: The SQL Way

SQL needs a fixed schema defined before any data goes in, and changing it later can rebuild the whole table. Rigid, but predictable and storage-efficient.

-- SQL table: schema defined upfront, rigid
CREATE TABLE users (
  id         SERIAL PRIMARY KEY,
  name       VARCHAR(100) NOT NULL,
  email      VARCHAR(200) UNIQUE NOT NULL,
  age        INT,
  created_at TIMESTAMP DEFAULT NOW()
);
-- Every row must have exactly these columns

Flexible Schema: The MongoDB Way

A MongoDB collection appears the moment you insert — no schema needed. This flexible schema is great for prototyping, but your code must handle missing fields.

// No schema definition needed - collection created on first insert
db.users.insertOne({ name: 'Alice', email: 'alice@test.com', age: 30 });

// Next insert can have completely different fields
db.users.insertOne({ name: 'Bob', email: 'bob@test.com', company: 'Acme', role: 'admin' });

// Both documents live in the same 'users' collection

Schema vs Schema-Less: The Trade-Off

Neither wins outright. Fixed schemas guard against bad data; flexible ones let you move fast. MongoDB's JSON Schema validation gives you optional middle ground.

Normalization vs Denormalization

SQL favors normalization — splitting data across tables. MongoDB favors denormalization — embedding related data together, so you read it all in one go without JOINs.

// SQL normalized: address in separate table
// SELECT u.name, a.city FROM users u JOIN addresses a ON a.user_id = u.id

// MongoDB denormalized: address embedded in user document
{
  _id: ObjectId('...'),
  name: 'Alice',
  address: { city: 'London', zip: 'EC1A' }   // no JOIN needed
}

Creating Collections Explicitly

Collections appear automatically, but createCollection lets you set options up front — like a capped collection for logs or a validator. The code shows one.

// Create a capped collection explicitly
db.createCollection('appLogs', {
  capped: true,
  size: 10485760,   // 10 MB maximum size
  max: 50000        // optional: max 50,000 documents
});
// When full, oldest documents are automatically removed

Listing and Dropping Collections

A few handy commands list, count, and drop collections. To empty one without deleting it, use deleteMany — there's no TRUNCATE in MongoDB. The code shows them.

// Useful collection management commands in mongosh
db.getCollectionNames();
// ['users', 'orders', 'products']

db.users.countDocuments({});
// 4823

db.users.stats().storageSize;
// 2097152 (bytes)

// Delete all documents but keep the collection:
db.users.deleteMany({});
// { acknowledged: true, deletedCount: 4823 }

The _id Field and Primary Keys

Every collection has _id as its primary key, with an automatic unique index. You can supply your own _id — like a product SKU — as long as it's unique.

// Custom _id values
db.products.insertOne({
  _id: 'SKU-HEADPHONES-BLK-42',   // string _id
  name: 'Wireless Headphones Black',
  price: 79.99
});

// Lookup by custom _id is O(log n) via the _id index
db.products.findOne({ _id: 'SKU-HEADPHONES-BLK-42' });

Index Structure Differences

Both SQL and MongoDB use B-tree indexes, but MongoDB can index nested fields and array elements too. So flexible schemas don't cost you query speed.

// Index a nested field and an array field
db.users.createIndex({ 'address.city': 1 });
// Now queries on city use an index:
db.users.find({ 'address.city': 'Chicago' });

// Multikey index on array field - indexes each element
db.products.createIndex({ tags: 1 });
db.products.find({ tags: 'electronics' }); // uses multikey index

Transactions: Tables vs Collections

Since v4.0, MongoDB supports multi-document transactions. But by embedding related data in one document, you often get atomic updates without needing them at all.

// Single-document atomicity (always available)
// Updating order status and adding a tracking number
db.orders.updateOne(
  { _id: orderId },
  { $set: { status: 'shipped', trackingNumber: 'UPS123456' } }
);
// These two field updates happen atomically - no transaction needed

When to Choose Tables Over Collections

Sometimes SQL tables are the better pick: stable schemas, heavy JOINs, or strict foreign-key integrity. Choose the right tool, not the trendiest one.

Quick Check

Test your understanding of MongoDB & NoSQL Databases concepts from this lesson.

Lesson Recap

You learned collections don't force a schema, MongoDB embeds related data to skip JOINs, and every collection auto-indexes _id. Next: databases and namespaces.

常见问题解答

「集合与 SQL 表的比较」课时是免费的吗？

是的 — 「集合与 SQL 表的比较」的完整文本可在网页上免费阅读。要进行交互式练习（内置代码编辑器和全天候 AI 导师）并解锁 MongoDB Academy 课程的其余内容，请升级到 CoddyKit PRO。 MongoDB Academy 课程共包含 4 节课。

「集合与 SQL 表的比较」这节课中我会学到什么？

您将对比 MongoDB 集合与关系型数据表，并理解灵活模式如何改变数据设计。 你通过在浏览器中直接运行的动手代码来练习 MongoDB Academy，全天候 AI 导师会在你学习这节课的过程中回答你的问题。

学习 MongoDB Academy 需要有经验吗？

无需任何先前经验。CoddyKit 上的 MongoDB Academy 课程适合初学者到高级学习者，你可以从这里开始或从头开始，按照自己的节奏学习。 这是第 2 节课，共 4 节。

「集合与 SQL 表的比较」课时需要多长时间？

大多数 CoddyKit 课程大约需要 5–10 分钟。每节课都很精短且互动，所以你能稳步进步，并在网页和应用中从离开的地方继续。

我能在这节 MongoDB Academy 课中编写并运行代码吗？

能。每节 MongoDB Academy 课都包含内置代码编辑器，你可以在浏览器中直接编写并运行真实代码，并获得即时 AI 反馈 — 无需本地设置。

此课程中的所有课时

  1. 什么是 BSON 文档
  2. 集合与 SQL 表的比较
  3. 数据库、集合与命名空间
  4. mongosh Shell 基础
← 返回 MongoDB Academy