这是15年想到的一个问题，今天看到了之前的文件，决定挺有趣的，想把它写出来，和大家分享一下。
问题背景。现有一个实体店商家想通过互联网销售自己的商品。请为他设计一个数据库。
当时毫不犹豫就是两张表，供货厂商表，商品信息表两者多对多，那就额外需要一张中间表。
好，一段时间后，老板说有些商品需要增加“长度”属性（基于现实考虑，有些商品也不需要“长度”属性）。那怎么办？为了节省空间 ，商品信息表再来一张表存长度（此时最好预留一些字段，假如老板又要添加一个“宽度”属性呢？ ）。
以为这就解决了，天真！ 假如老板要添加一个属性，这个属性与“长度”和“宽度”存在依赖关系，那怎么办？？。那就得再来一张表。 而且发现一个问题没有？ 老板（需求）提的要求是在当前表下的最优解，这是局部最优解，那一般是很难达到整体最优解的。 那要怎么办？
（解决问题的过程就是提高的过程。）
我的解决方案：
再设计之初 商品信息应该分类（不能将所有商品放在一个“类里”，有点“面向对象”的意思哈，这是我15年的想法），分类之后，哪些商品需要“A”属性，先看看该类商品是否有预留字段，有最好，没有可以再添加也可以额外加表、关联。这样做有两点好处，第一节省空间，第二减少了表之间的“耦合度”