序
本文将介绍如何基于 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＋PHP＋MYSQL
系统模块：
应用中心
属性中心
标签中心
从技术角度描述RBZ的运转流程大致如下：
通过［属性中心］配置和管理属性。
通过［标签中心］配置和管理标签。
通过［应用中心］选择［实体、属性、标签］，自动生成表单，录入数据。
通过［CMS］动态模版输出给C端用户。
下面逐一讲解，他们分别是什么。：）无比接近干货地段了。
系统设计
架构
表结构
基于列模式的表设计。（我们常规的工作都是行模式）
举个栗子：A公司售卖鞋子和衣服。（比较极端，勿喷）
行模式（产品表）
| PID | PNAME | 类型 | 尺码 | 颜色 |
|---|---|---|---|---|
| 0001 | 鞋子1 | 1 | 42 | 黑色 |
| 0002 | 衣服1 | 2 | XL | 蓝色 |
列模式（属性表、实体表）
属性表（类型、排序、启用、默认值、可选值、必填…）
| 属性ID | 属性名称 | 属性字段 | 数据类型 | 属性分组 |
|---|---|---|---|---|
| 1 | 尺码 | size | input | 鞋子 |
| 2 | 尺码 | size | input | 衣服 |
| 3 | 颜色 | color | input | 鞋子 |
| 4 | 颜色 | color | input | 衣服 |
实体表
| ID | 应用ID | 实体ID | 属性ID | 属性值 |
|---|---|---|---|---|
| 1 | 1 | 0001 | 1 | 42 |
| 2 | 1 | 0001 | 3 | 黑色 |
| 3 | 1 | 0002 | 2 | XL |
| 4 | 1 | 0002 | 4 | 蓝色 |
这番设计，两个益处。
省存储空间。
易动态扩展。
动态表单
我们的常规工作是静态表单，避免在Code Monkey的路，越走越远，我们需要改变。
设计动态表单模型，基本的思路应该是数据和表现显示的分离。抛开表现层，一个表单包含的若干个字段和填写的数据。所谓动态，就是这些字段名称可能改变，数量可能有增减。
配置字段（POI中文名称）
配置中。。。
见证奇迹的时刻。（表单自动生成）
这番设计，两个益处。
猴子做架构了（再也不用写FORM了）。
用户自定义。
CMS
通过CMS定义RBZ标签，结合自定义样式模版，任意组合吐出数据。
用了一个叫 Mustache 的模版语言。
{{#cmsRbzItems}}
中文名称 {{attr_cnname}}
英文名称 {{attr_enname}}
岛屿图片 {{attr_pic}}
所属群礁 {{attr_class}}
酒店品牌 {{attr_hotel}}
费用信息 {{attr_price}}
产品推荐 {{attr_managerrecommend}}
岛屿星级 {{attr_islandstar}}
岛屿排序 {{attr_islandrank}}
上岛时间 {{attr_timecost}}
{{/cmsRbzItems}}
API
为确保RBZ接口的持续交付，我们选择用 Postman 来做接口的自动化测试工作。
某一个请求。
每一次发布。
RBZ－应用
处子秀：马尔代夫选岛工具
需求：
提取马尔代夫的所有岛屿（POI）
扩展岛屿属性（费用信息、岛屿星级、产品经理推荐）
给岛屿打标签（蜜月、亲子、一价全含、WIFI）
选岛工具
只需配置，无需研发。
配置属性
配置标签
配置应用
选POI
编辑属性
编辑标签
灯灯灯灯。。。
筛选项：
实体：
在这里，代表官方，诚邀各种应用接入。
RBZ－ROI
浅谈RBZ的回报率。
成就工作快，降成本，提效率。（之前这样的后台开发任务至少需要15人天）。
可能成为运营层数据字典。
聚合页需求配置化。
精细化运营：脱离底层数据，在运营层通过属性、标签配置，精细化呈现。
结论
理解EAV模型确实需要时间。它有一个明确的学习曲线，使的初级开发人员在真正理解其概念前，需要为此付出更多的精力。
应用实体-属性-值时，应考虑以下条件：
数据是稀疏的、异构的，一个实体的属性范围较广，且常引入新的属性。
类的数量非常大，有许多实例类，即使属性是非稀疏的。
结束语
我们的终极目标是：
人人都是程序员。
