序
本文将介绍如何基于 EAV 模型,来构造一个准自动化的运营系统,服务运营研发部的相关工作。
我们的痛点
运营研发部对接三端(PC、M、APP)后台工作,劳心劳力。。。
- 头疼的稀疏表( 稀疏表通常会有很多列,但是每一行有值的列又比较少。)+头疼的各种表。
- 持续的迭(xu)代(qiu)升(bian)级(geng)(每一次功能升级,都需要变更表结构)。
- 基础数据的维护代码坑好多,打个标签加个属性,都好怕。
- Code Monkey,熟悉的表+熟悉的套路(设计表单、设计字段、CRUD…)Boom!
漫漫选型路
其实我们的愿景很“简单”。
- 可以舒服地给各种[途牛实体]打标签、扩展属性。
- 可以简单地记录任何结构的新数据,而不需要修改任何数据结构。
- 可以极好地迅速扩展应用,因为它可以防止(属性)不断变化的后果。
漫漫长路。。。
为了高可用&扩展性,我们学习了Drupal的元数据操作、Magento的产品建模、以及各种CMS。
为了解决稀疏表,我们尝试基于 Column Family(列族)来处理,BigTable、Cassandra、HBase,曾经都是我们的“座上客”。(事实上,很多团队已经这样解决掉了)
然而,
踏破铁鞋无觅处,得来全不费工夫。
一种数据模型悄然而至,实体属性值模型。
来自百度百科:实体属性值模型(EAV)是一种用数据模型描述实体的属性(属性,参数),可以用来形容他们潜在巨大,但实际上将适用于给定的实体的数量是相对较少。 在数学中,这种模式被称为一个稀疏矩阵 。 EAV也被称为对象的属性值的模式,垂直的数据库模型和开放式架构。
这里不详细介绍EAV是什么,因为我们的设计在EAV之上。(站在巨人的肩膀上)
下面即将进入全文干货集中地段。^_^
RBZ
系统代号:RBZ(肉包子)
系统构成:EAV+DF+AC