一双鞋引发血案：产品化数据建模浅析.pdfVIP

一双鞋引发的血案 ：产品化数据建模浅析 这是一个发生在 2015年 的故事。中国的互联 经济进入高速发展的时期。各种互联 创业公司层 出不穷 ，人们争先恐后地加入到这场浪潮中来。 故事的主人公小明是个有远大理想的小朋友 ，有一些的开发经验 ，更有敏锐的市场洞察力。 他发 现以 uber 和 airbnb 为代表的共享经济正在变成一个热点 ，新加入的 “回家吃饭 “也是来势汹汹。这 些公司涵盖了食、住、行等领域的共享 ，但市面上还没有衣服共享的公司。他又想到自己有很多闲 置的运动鞋 ，何不开一个在垂直领域共享运动鞋的创业公司。他兴奋得一夜没睡 ，马上注册了一 个叫 air-sneakers 的公司。召集了几个工程师朋友热火朝天地干起来了。 创业艰辛 首先他们着手设计数据模型。在数据模型中最重要的表叫 AT HLET IC_SHO ES 表。这个表大概长 成这样 ： 小明又为常用的一些品牌 ，材料 ，尺码等重要数据建了一些关联表。接着 ，小明又做好了 PRD 和 w iref ra e。 小明的工程师们选择了熟悉的 java 语言来开发。每个页面基本针对一张表的增删改查 ，用 iBat is 之类的 O R apping 开发的后端和 angular 开发的前端很快就完成了。两个月后第一版 上线了! 很快 ，小明注意到了一个问题。并不是很多人都有很多闲置的运动鞋 ，也不是每个人都喜欢每天穿 不同的运动鞋。和公司 CFO （小明太太 ）商量后 ，他果断决定推出女鞋共享 ，女人的闲置鞋会多 一些。 小明的工程师发现原来设计的数据模型根本不够用。女鞋可不像运动鞋那么简单 ，光一个单鞋就有 什么高跟 ，低跟 ，平跟 ，粗跟 ，细跟 ，圆头 ，尖头 ，真皮 ，假皮等等属性 ，连鞋码都不一样。新的 女鞋表大概是这样的. W O MENS_SHO ES 当然还有 W O MENS_ PUMPS 表 ，W O MENS_ BO OT S 表 ，W O MENS_SA NDA LS 表 ，等等… …此处略去 10000 字 原来的代码基本上没用了 ，小明还被工程师打了。 新的代码花了很长时间才写出来 ，特别复杂 ，到处都是 if else 之类的判断。总算 ，新版本上线了。 但是用户还是不买账。原来 ，女人也不喜欢穿别人的旧鞋 ，也没有那么多人喜欢把自己的鞋借给 别人 ，过上脚气都不知道。 小明再次调整战略 ，开发出了一版包括所有服装共享的 app 改名为 air-wardro be。这次新的表结构 就没那么简单了 ，大大小小建了上百张表。 大家天天加班 ，苦苦干了一年。因为屡次改需求 ，小明又受伤住院了。 峰回路转 总算 ，新 app 上线为小明拉来了第一笔风投。投资方不希望小明只做服装共享 ，应该涵盖所有家用 产品。无奈下 ，小明找来了一个架构师设计新的数据模型。架构师看到旧的 sche a 设计抚掌大笑 ，指出了旧 sche a 的最大问题。 传统横向 sche a 的缺点 ： 在插入数据时 ，需要向许多张表里先后插入数据 ，并要保证数据的一致性。 当需要显示来自不同表的信息时 ，需要连接多张表。前端在显示产品列表时要显示的字段常常不 在一张表里。经常为了显示一个字段而要多连接几张表 ，并做各种复杂的查询。 一个表的列越多 ，数据冗余也越多 不同的维度 ，事实和度量需要建立跟多的错综复杂的关系 ，并要维护这些一致性。 所有传统关系型数据库的缺点 新数据模型是这样设计出来的。首先是一张 PRO DUCT 表。这张表包含了世界上所有产品共有的 属性。如分类 ，新旧 ，价格 ，数量。 然后 ，那些为各类商品单独建的表和它们的关联表都不需要了。取代他们的是一个垂直的 sche a. 首先需要的是一张表描述商品的元数据 （ et a dat a ）“PRO D_AT T RIBUT ES” ，用来存放所有产品 属性的定义。 对于每一种商品 ，我们只需要定义他们独有的属性 ，不同商品可以共享一些属性 ，比如运动鞋和女 鞋共享鞋码的属性。 对每样商品的每个属性 ，我们插入一条数据来保存它。这就需要一个 PRO D_AT T R_VA LUE 表 过去我们选择一条商品数据用这样的 SQ L ：Select * f ro at hlet ic_shoes w here id = 1001 现在用的 SQ L 还是一样 ：Select * f ro PRO D_AT T R_VA