商品属性存储假设

在上一篇文章ecshop存储商品各属性库存数量中，我讲了两种使用关系性数据库来存储的方式，分别是可能性2和ecshop采取的方式，这里我突然感觉还有点想法，所以在这里再记述一下。

可能性2

可能性2采取的方式的确能很好的保证针对每个属性的筛选都能得到具体的商品，而且针对商品能设置的参数更多，甚至能针对到每个属性的组合，但是这样换来的代价就是商品表会变得异常庞大，商品的各个属性之间会进行笛卡尔积的运算，运算结果就是商品表的条数。

ECSHOP采取的方式

ecshop采取的方式其实是换汤不换药，将可能性2中的商品表的一些信息摘取出来，组成一个张goods表，再来将剩余的这些信息保存到product表中，其实记录的数量还是一样的多。

我的设想

其实我感觉记录商品的各个属性下的库存数量就像一棵树一样：

属性1名称	属性2名称	……	属性N名称	最终结果
篮球鞋	玫瑰红	……	塑胶底	对应的库存数量或者价格
	运动紫	……	……
		……	人造革
登山鞋	玫瑰红	……	塑胶底
……

每次都改变其中一个属性的值，剩余字段不变，这样就造成了记录很多。可是其实我们想要的记录无非值最后的结果，就是最终结果，前面的字段都是指向的路灯，指引我们找到最后的结果。那么有没有可能将路灯简化一点呢？比如说将路灯的转换成特定的编码：

• 第一部分表示商品的种类，不足的话使用0在前面补齐
• 第二部分表示商品所具有的属性1，接着的部分表示商品所具有的属性2，以此类推，设置商品的总属性最多为10个，或者更多，属性没有那么多的话就使用0来补齐。这样的话就可以将多个属性字段全部压缩在一个属性字段里面了。

最后再加一个库存字段或者价格字段，就可以通过key-value的模式将信息保存起来了。当然这是有代价的，就是这样就无法使用关系性数据库中的主外键约束了，而且这字段本身就是违反范式的存在。

所以我想试试使用nosql来存储，Mongodb，memcache或者redis，都可以存储key-value的形式，即使商品数量庞大，也可以使用分片技术。而且由于memcache和redis都是缓存型数据库，读写速度也快于mysql，配合上快照和主从数据库配置，也能保证即使一台服务器当机之后仍能运行。这样貌似没有什么问题。可能也是我想法太天真了，但是谁一辈子没傻过啊，所以记录在这里，等以后更有能力了再来修改与补充。