84669인 학습
152542인 학습
20005인 학습
5487인 학습
7821인 학습
359900인 학습
3350인 학습
180660인 학습
48569인 학습
18603인 학습
40936인 학습
1549인 학습
1183인 학습
32909인 학습
今天研究shopnc的数据表结构,发现很多表不按照三范式来建表,很多表都是相关字段重复。
优点是很多时候不用关联表进行查询了。 缺点是不按照三范式规范,而且如果中途改一个表的字段后,相应的表也应该进行修改,但到那个时候已然发现不好改了,因为可能涉及的表太多太多了。
优点是很多时候不用关联表进行查询了。
缺点是不按照三范式规范,而且如果中途改一个表的字段后,相应的表也应该进行修改,但到那个时候已然发现不好改了,因为可能涉及的表太多太多了。
所以我想直到怎么取舍这个问题。
认证0级讲师
通常先考虑性能,如果冗余一个字段能够减少很多关联查询,那么通常会选择冗余,而不是去追求第三范式。例如文章详情页通常会有评论数,这个评论数通常会冗余在文章表中,而不是每次去评论表中统计。但是反范式也有缺点:维护的字段多了,数据可能不一致,存储空间也大了等等。这就要看是否能灵活运用了
一般来说,为了性能做冗余是必须的;至于你说的如果一个表的值改影响冗余的信息这个,一般是通过产品来规范, 要么冗余的信息在定义的表里不允许更改,例如你注册时的用户名; 要么定义的信息改变后不对冗余的信息做更新,例如你购买商品生成订单时保存在订单上的商品标题信息。
楼上说的对这都需要进行取舍
通常先考虑性能,如果冗余一个字段能够减少很多关联查询,那么通常会选择冗余,而不是去追求第三范式。
例如文章详情页通常会有评论数,这个评论数通常会冗余在文章表中,而不是每次去评论表中统计。
但是反范式也有缺点:维护的字段多了,数据可能不一致,存储空间也大了等等。
这就要看是否能灵活运用了
一般来说,为了性能做冗余是必须的;
至于你说的如果一个表的值改影响冗余的信息这个,一般是通过产品来规范,
要么冗余的信息在定义的表里不允许更改,例如你注册时的用户名;
要么定义的信息改变后不对冗余的信息做更新,例如你购买商品生成订单时保存在订单上的商品标题信息。
楼上说的对这都需要进行取舍