返回模板页

ER 图示例

下面这些案例展示了开发者最常遇到的表结构和关联关系。每个案例对应一个真实的应用领域，帮你理解实体如何连接，并根据自己的项目调整 schema。

使用这个模板返回模板页
ER 图示例

真实案例

电商系统 schema

使用场景: 后端开发者或架构师，设计在线商店数据库

Customer（id PK, email, name, created_at）
Address（id PK, customer_id FK, street, city, country）
Product（id PK, name, price, category_id FK, stock）
Order（id PK, customer_id FK, address_id FK, status, total）
OrderItem（id PK, order_id FK, product_id FK, quantity, unit_price）
Category（id PK, name, parent_id FK）

这样组织的原因: 把地址从用户表分离、把订单明细从订单表分离，保持 schema 范式化——一个用户可以有多个地址，一张订单可以包含多个商品，不产生数据冗余。

多租户 SaaS schema

使用场景: 全栈开发者，设计面向多客户账号的 B2B SaaS

Organization（id PK, name, plan, created_at）
User（id PK, org_id FK, email, role）
Project（id PK, org_id FK, name, status）
Task（id PK, project_id FK, assignee_id FK, title, due_date）
Comment（id PK, task_id FK, user_id FK, body, created_at）
AuditLog（id PK, org_id FK, user_id FK, action, created_at）

这样组织的原因: 每张表都带一个 org_id 外键，确保所有查询都能限定在单个租户内——ER 图在写代码之前就把隔离边界画清楚了。

博客 / CMS schema

使用场景: 开发者，搭建内容管理系统或 Headless CMS

Author（id PK, name, email, bio）
Post（id PK, author_id FK, title, body, status, published_at）
Tag（id PK, name, slug）
PostTag（post_id FK, tag_id FK）— 关联表
Comment（id PK, post_id FK, author_name, body, approved）
Media（id PK, post_id FK, url, type, alt_text）

这样组织的原因: PostTag 关联表处理文章和标签之间的多对多关系，避免在每行文章中重复存储标签数据——这是值得在图中明确画出来的常见 schema 模式。

医院管理系统 schema

使用场景: 开发者或分析师，搭建医疗记录系统

Patient（id PK, name, dob, gender, contact）
Doctor（id PK, name, specialty, department_id FK）
Department（id PK, name, location）
Appointment（id PK, patient_id FK, doctor_id FK, date_time, status）
Prescription（id PK, appointment_id FK, medication, dosage）
Billing（id PK, appointment_id FK, amount, paid_at）

这样组织的原因: 把处方和账单关联到就诊记录而不是直接关联到患者，让每条临床和财务记录都可以追溯到具体的一次就诊——对审计和合规非常重要。

社交网络 schema

使用场景: 开发者，搭建带关注、动态和互动功能的社交 App

User（id PK, username, email, avatar_url）
Follow（follower_id FK, following_id FK）— 关联表
Post（id PK, user_id FK, body, created_at）
Like（user_id FK, post_id FK）— 关联表
Comment（id PK, post_id FK, user_id FK, body）
Notification（id PK, user_id FK, type, ref_id, read）

这样组织的原因: Follow 表是 User 自身的多对多关联——在 ER 图中画出来，能清楚地表明 follower 和 following 都是指向同一张表的外键。

库存管理 schema

使用场景: 开发者，搭建仓库或库存管理系统

Product（id PK, sku, name, category_id FK, unit_cost）
Warehouse（id PK, name, location）
Stock（id PK, product_id FK, warehouse_id FK, quantity）
Supplier（id PK, name, contact, lead_days）
PurchaseOrder（id PK, supplier_id FK, status, expected_date）
POItem（id PK, po_id FK, product_id FK, quantity, unit_price）

这样组织的原因: Stock 表是 Product 和 Warehouse 之间的关联——明确建模后，同一个 SKU 可以在多个仓库独立追踪库存，不会相互干扰。

使用技巧

  • 每个实体框里一定要展示主键和外键——只画关系线而不标注关联字段，读图的人还是搞不清楚。
  • 一致使用鱼尾符号标注基数：分叉端在多的一侧，单线端在一的一侧。
  • 即使在概念图阶段，多对多关系也要通过关联表显式画出——否则到了实现阶段容易产生误解。
  • 图中的属性列表不用完整——只展示主键和少数重要字段，完整列字段清单放在 schema 文档里，不要塞进 ER 图。

在线开始编辑

回到模板页，直接替换成你的课程主题、章节和复习重点，就可以继续使用这套结构。

使用这个模板： /editor/new?template=erd

使用这个模板