项目记录一

尚筹网

项目架构

前台（客户使用的系统）
后台（管理员使用的系统）

前端	前台
后端	后台

数据库和数据库表

物理建模

• 第一范式：数据库表中的每一列都不可再分，也就是原子性
  
  例如，上表中的“部门”和“岗位”应该拆分成为两个字段：“部门名称”和“岗位”。
  
  这样才能够专门针对“部门”或者“岗位”进行查询。

• 第二范式：在满足第一范式基础上要求每个字段都和主键完整相关，而不是仅和主键部分相关（主要针对联合主键而言）。

“订单详情表”使用“订单编号”和“产品编号”作为联合主键。此时“产品价格”、"产品数量"都和联合主键整体相关，但是“订单金额”和“下单时间”只和联合主键中的"订单编号"相关，和"产品编号"无关。所以只关联了主键中的部分字段，不满足第二范式。

把"订单金额"和"下单时间"移到订单表就符合第二范式了。

• 第三范式：表中的非主键字段和主键字段直接相关，不允许间接相关。

上面表中的"部门名称"和"员工编号"的关系是"员工编号"->“部门编号”->“部门名称”，不是直接相关。此时会带来下列的问题：

• 数据冗余："部门名称"多次重复出现
• 插入异常：组建一个新部门时没有员工信息，也就无法单独插入部门信息。就算强行插入部门信息，员工表中没有员工信息的记录同样是非法记录。
• 删除异常：删除员工信息会连带到删除部门信息导致部门信息的以外丢失。
• 更新异常：哪怕只修改一个部门的名称也要更新多条员工记录。

正确的做法是：把上表拆分成两张表，以外键形式关联。

"部门编号"和"员工编号"是直接相关的。

第二范式的另一种表述方式是：两张表要通过外键关联，不保存冗余字段。例如：不能在"员工表"中存储"部门名称"。

实践

• 规则的变通
  三大范式是设计数据库表结构的规则约束，但是在实际开发中允许局部变通。
  比如为了快速查询到关联数据可能会允许冗余字段的存在。例如在员工表中存储部门名称虽然违背第三范式，但是免去了对部门表的关联查询。
• 根据业务功能设计数据库表
  • 看得见的字段
    能够从需求文档或者原型页面上直接看到的数据都需要设计对应的数据库表、字段来存储。

根据上面的原型页面我们看到管理员表需要包含如下字段：

• 账号

• 密码

• 名称

• 邮箱地址

• 看不见的字段
  除了能够直接从需求文档中看到的字段，实际开发中往往还会包含一些其它字段来保存相关数据。
  例如：管理员表需要再增加如下字段以有利于数据的维护

  • 主键
  • 创建时间

• 冗余字段
  为了避免建表时考虑不周有所遗漏，到后期再修改表结构非常麻烦，所以也有团队会设置一些额外的冗余字段备用。

• 实际开发对接
  实际开发中除了一些各个模块都需要使用的公共表在项目启动时创建好，其它专属于各个模块的表由该模块的负责人创建。但通常开发人员不能直接操作数据库服务器，所以需要把建表的SQL语句发送给运维工程师执行创建操作。