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语句将变得简单,且便于查询到的数据进行封装的操作;
一旦数据库设计不太合理,后端人员就需要使用大量的复杂的逻辑去弥补数据库设计的漏洞,不利于后端程序的开发。所以在进行开发时,一旦发现数据库设计有不合理之处,就需要想清楚,及时进行修改。数据库的设计是一个技术活,要多看、多分析、多练;一个合理的数据库,可以省去后端大量的麻烦,大大提高开发效率。