Javaweb项目介绍：OnlineShopping

ER图设计遵循三大范式：

第一范式：要求任何一张表必须有主键，每一个字段原子性不可再分；

第二范式：建立在第一范式的基础之上，要求所有非主键字段完全依赖主键，不要产生部分依赖（用一张表中同时存有学生与老师的关系来理解；）

第三范式：建立在第二范式的基础之上，要求所有非主键字段直接依赖主键，不要产生传递依赖；

设计数据库表的时候，按照以上范式进行，可以避免表中数据的冗余，空间的浪费。

以下是三大范式对应着表关系的应用：

• 多对多，三张表，两个外键【第二范式 联合主键的情况】

• 一对多，两张表，多的表加外键【第三范式】

• 一对一，外键唯一

本项目的ER图设计很简单，两个最主要的表是用户表和商品表。辅助表是订单表、购物车表。字段名要避开一些关键字，不仅仅是SQL语言的关键字，还包括后端语言（Java、Go）、前端Ajax的关键字（如：order、status）

用户表和商品表的关系是一对多，即一个用户可以上传多个商品，但一个商品只能被一个用户所上传，所以我们需要在商品表中建立外键，关联用户的id。

商品表与购物车表的关系是多对多，即一个商品可以被添加到多个购物车当中，一个购物车中可以添加多个商品，所以我们需要建立一个商品和购物车的关系表，其中两个字段分别关联商品Id和购物车Id。

商品表与订单表的关系也是多对多，即一个商品可以被多个用户所购买产生订单信息，这里的一个商品并不是指的一个抽象的商品名，而是指一个具体的商品实体，即一个商品可以有多个数量。一个订单中也有可能包含多个商品，用户在购买的时候，将多个商品一起进行购买,比如用户一次性购买了所有购物车中的商品信息。所以需要建立一个订单与商品的中间表，表示二者中间的关系。

在进行数据库设计的时候，不要过分地追求数据库的低冗余，有时候数据冗余是可取的，具体看实际的需求。需要说明的是：数据库设计的三大范式是理论上的，实践和理论有时候有偏差，最终的目的都是为了满足客户的需求。在数据库设计的时候，有时候会拿冗余换执行速度，因为在sql中，表和表之间连接次数越多，执行的效率越低。有的时候在数据库设计的时候可能会故意冗余，主要是为了减少表的连接次数，这样做也是合理的，并且对于开发人员来说，sql语句的编写难度也会降低。

为加深读者的印象，以本项目为例：现提出一个需求：我们需要根据商家的Id，去查找其商品被购买的记录；

正常设计的话，用户与商品的关系是一对多，我们需要在商品表中设计一个字段merchantId来表示商家的Id，这一个Id，使用外键关联到对应的用户Id上。而其他地方，就不应该出现表示商家的信息了。

从ER图中我们可以看到，如果其他地方不再出现商家信息，我们需要先获取订单的id,再拿着订单的id去在商品和订单关系表中去查看对应的商品id，在拿着商品的id去商品表中查询商家的id是否与所要查询的商家id一致。这一个过程相当于多表联查，查询了三个表，具体的SQL语句如下:

select * from merchandise left join order_merchandise left join `order` on 
`order`.id = order_merchandise.orderId on merchandise.id = order_merchandise.merchandiseId 
where merchandise.merchantId = 1 order by purchaseDate;

SQL语句过于复杂，并且查询效率低，这时候如果我们在订单与商品表的字段上添加与商品Id对应的商家Id,这时候我们的SQL语句将变得简单，且便于查询到的数据进行封装的操作；

一旦数据库设计不太合理，后端人员就需要使用大量的复杂的逻辑去弥补数据库设计的漏洞，不利于后端程序的开发。所以在进行开发时，一旦发现数据库设计有不合理之处，就需要想清楚，及时进行修改。数据库的设计是一个技术活，要多看、多分析、多练;一个合理的数据库，可以省去后端大量的麻烦，大大提高开发效率。