数据库表设计

数据库表设计笔记

一、需求分析

• 明确业务场景：确定系统需存储的数据类型（如用户、商品、订单等）。
• 梳理数据关系：分析数据关联（一对一/一对多/多对多）。

二、表结构设计

1. 划分主题表

• 每张表围绕单一主题（如「用户表」「商品表」），避免混合无关数据。

2. 定义字段

• 业务适配：字段需覆盖业务需求，避免冗余或缺失（例：用户表含userId、userName、phone）。
• 命名与类型：
  • 命名规范（如驼峰式：orderTime）；
  • 类型匹配（如整数用INT，文本用VARCHAR）。

三、约束与关联设计

1. 主键约束

• 每张表必须设置主键（如自增ID），唯一标识记录。

2. 外键关联

• 通过外键建立表间关系（例：订单表userId关联用户表userId），保障数据完整性。

3. 数据约束

• 非空约束（NOT NULL）：必填字段（如userName）。
• 唯一约束（UNIQUE）：避免重复数据（如phone）。
• 检查约束（CHECK）：限制取值范围（如age > 0）。

四、规范化设计

1. 第一范式（1NF）

• 核心规则：字段原子性，不可再拆分（例：地址拆分为province、city、district）。

2. 第二范式（2NF）

• 前提：已满足1NF。
• 规则：消除部分依赖（组合主键场景下，非主属性需完全依赖整个主键）。
  • 例：订单明细表主键为(orderId, productId)，productName需依赖全部主键，而非仅productId。

3. 第三范式（3NF）

• 前提：已满足2NF。
• 规则：消除传递依赖（非主属性直接依赖主键，而非通过其他非主属性）。
  • 例：订单表不存储userName，通过外键userId关联用户表获取。

五、性能优化

1. 索引设计

• 为高频查询字段添加索引（如订单表createTime），避免过度索引影响写入性能。

2. 字段类型优化

• 选择轻量级数据类型（如用TINYINT存储状态值替代INT）。

3. 分表策略

• 数据量大时按时间/业务拆分（如order_current与order_history）。

六、示例：电商系统表结构

表名	主键	核心字段	外键关联
用户表	userId	userName、phone、email	无
商品表	productId	productName、price、stock	无
订单表	orderId	orderTime、totalPrice、userId	userId → 用户表
订单明细表	orderItemId	orderId、productId、quantity	orderId → 订单表 productId → 商品表

七、注意事项

• 平衡规范化与性能：允许适当冗余减少联表查询（如订单表冗余存储userName）。
• 文档化：记录字段含义、表间关系，便于维护。
• 预留扩展：添加extInfo字段（JSON格式）应对需求变更。

数据库相关范式详解

第一范式（1NF）

核心要求：字段原子性，每个字段存储单一值，不可拆分。

• ❌ 反例：字段address存储「北京市朝阳区XX路」（可拆分为省/市/区）。
• ✅ 正例：拆分为province、city、district三个字段。

第二范式（2NF）

核心要求：消除部分依赖，非主属性完全依赖主键（适用于组合主键场景）。

• ❌ 反例：订单明细表(orderId, productId, productName)，productName仅依赖productId（部分依赖）。
• ✅ 正例：拆分出商品表，订单明细表仅保留productId，通过外键关联商品表获取productName。

第三范式（3NF）

核心要求：消除传递依赖，非主属性直接依赖主键，而非通过其他非主属性。

• ❌ 反例：订单表(orderId, userId, userName)，userName通过userId间接依赖orderId（传递依赖）。
• ✅ 正例：订单表仅保留userId，userName存储于用户表，通过外键关联查询。

第四范式（4NF）

核心要求：消除多值依赖，确保表中无独立的多值属性组。

• ❌ 反例：教师表(teacherId, course, project)，一个教师对应多门课程和多个项目，课程与项目无关联（多值依赖）。
• ✅ 正例：拆分为teacher_course表和teacher_project表，分别存储教师与课程、教师与项目的关系。
  格与正文保持间距，避免内容堆砌。