关于数据库表设计的一个问题

这是15年想到的一个问题,今天看到了之前的文件,决定挺有趣的,想把它写出来,和大家分享一下。

问题背景。现有一个实体店商家想通过互联网销售自己的商品。请为他设计一个数据库。

当时毫不犹豫就是两张表,供货厂商表,商品信息表两者多对多,那就额外需要一张中间表。

好,一段时间后,老板说有些商品需要增加“长度”属性(基于现实考虑,有些商品也不需要“长度”属性)。那怎么办?为了节省空间 ,商品信息表再来一张表存长度(此时最好预留一些字段,假如老板又要添加一个“宽度”属性呢? )。

以为这就解决了,天真! 假如老板要添加一个属性,这个属性与“长度”和“宽度”存在依赖关系,那怎么办??。那就得再来一张表。 而且发现一个问题没有? 老板(需求)提的要求是在当前表下的最优解,这是局部最优解,那一般是很难达到整体最优解的。  那要怎么办?

(解决问题的过程就是提高的过程。)

我的解决方案:

再设计之初 商品信息应该分类(不能将所有商品放在一个“类里”,有点“面向对象”的意思哈,这是我15年的想法),分类之后,哪些商品需要“A”属性,先看看该类商品是否有预留字段,有最好,没有可以再添加也可以额外加表、关联。这样做有两点好处,第一节省空间,第二减少了表之间的“耦合度”

 

转载于:https://www.cnblogs.com/smellpawn/p/10811261.html

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值