服装这类商品不仅设计商品自身，还可能涉及属性，各属性笛卡尔积则是实际可选的商品类型，不仅如此，各最终可选的商品可能还涉及库存等信息。不仅在关系型上，NoSQL 解决这类问题也是比较乏力的。
比较经典的例子就是服装，涉及颜色、尺码以及对应的库存。
-
单商品设计：每种不同属性都当做不同的商品。这种违反了数据库设计范式的结构会导致极大的数据库冗余，后期难扩展、业务维护较麻烦。
-
SPU SKU 设计：通用字段与属性分开存储，这部分可以通过搜索引擎查询 ，不再赘述。这种设计模式对单类型商城是比较完美的解决方案，但是对于多商品的商城，如衣服的 SKU 表就是颜色、尺码、库存这三大属性，手机的 SKU 表则可能时 RAM 容量、ROM 容量、颜色、库存，难不成各类商品的 SKU 单独放一张表？可以看看 掘金 的这篇博文，写的比较好，缺点也比较明显，数据库里直接存的 JSON，后期难以维护。
-
横纵分表：参考淘宝的设计，知乎 上这个图比较能说明问题，缺点就是商品体系太复杂了，项目是好维护了，但是商品后台维护工作量大，且需要预先设计的表太多太杂，对于小项目来说有点不切实际。
不是所有东西都有自己认为完美的方案。
后面再看看吧。