Saas.扩展字段 自定义字段

为什么需要扩展字段

一个产品不可能罗列出所有的字段，比如：员工表，你能罗列所有企业OA系统中员工的信息字段吗？ “不可能的”。 咱也别有穷举这种妄念。管理方面理解： 固定规则和自由度需要结合起来，总公司不能把子公司规定死死的，也需要给一定的自由度灵活处理。固定规则为了保证秩序，业务系统中是为了保证系统可以正常运行，自由度是为了适配各地各种没有预想到的场景，业务系统中就是预留可扩展字段给用户，这样方可为上册。

多一嘴：有一些人只是从技术角度看系统，说明他只在看山还是山的第一层。搞Saas的都再这一层会遇到天花板的。Saas其实是做一个平台，这个平台要可以兼容解决大千世界无数场景的问题，就需要设计一套原则或者制度来保证都能处理到，这个维度看，不就跟中央要设计一个制度去治理一个国家吗？ 如果你能想到可能的问题，可以留言讨论，想不到可能的问题说明理解不了，直接跳过这段。

方案选型

1. 文档型数据库

2. 关系型数据库(横表) + JSON

3. 关系型数据库(纵表)

4. 关系型数据库(横表) ： 固定业务字段 + 预留字段 + 元数据

5. 关系型数据库(横表) ： 固定系统字段 + 预留字段 + 元数据

6. 列数据库Hbase

7. 混合方案，举例Salesforce

文档型数据库

MongoDB，存储的是Json啥都可以存储

缺点：事务支持不怎么好；数据不直观，增加后面运维的难度；复杂的join不支持；

从考虑到放弃： 字段不确定很容易想到存储JSON的MongoDB，然而毕竟涉及思想不同，现有开发思想大部分是基于关系型二维表，开发涉及过程的管理，生态和工具的支持，以及二维表天然的数据不会冗余特性，真正冗余了怎么保证数据的一致性，或者说你怎么能确定数据没有冗余。比如：订单中存储了详情的数据，然这样的数据到底有多少，经过几年的开发和人员流通后你能知道？

总结：如果只从是否可实现的角度看，可以。但加上其他因素不可以。

关系型数据库(横表) + JSON

Mysql+JSON字段(5.8 以上版本)

缺点：
1、从json中去统计某个字段数据之类的很麻烦，而且效率低。
2、查询相对效率较低，操作复杂。
3、更新其中某个字段效率较低，不适合存储业务逻辑复杂的数据。
4、统计数据复杂，建议需要做报表的数据不要存json。

总结：如果不需要根据json来统计数据或者局部更新json，仅是简单的读取或者整体覆盖，对于需要存取一个很大的有结构的数据，那json是较佳选择。

试用场景：扩展的字段只是用来做信息的补充，可以按照值对象(DDD中将省市县这种分开查询的比较少的场景就存储为一个json串)存储

Mysql+MongoDB

比较鸡肋，涉及到夸数据库操作，并且不同类型。还不如只有Mysql或者只用MongoDB呢

Mysql+JSON字段+MongoDB

MongoDB作为JSON数据的缓存

或者MongoDB作为Mysql中数据的缓存来查询，冗余了数据但兼容了有点

缺点：数据一致性保障，对开发和框架有要求

关系型数据库(纵表)

什么是纵表

1. 属性值 依赖 某个品类的某个对象(对象ID)的 某个属性值(属性ID)，且某个对象的属性值可变，又没法记录，但属性值在某时刻或者某时间段(时间区间)是固定值，所以才可记录
2. “是否当前有效”标识是否是 对象的当前(现在)的属性值
3. “是否有效”标识 该数据是否有用，可能是错误数据，删除了，没用了。

 没有优点和不足

只是一种方案，这么存储数据效率太低了。看也不好看， 查询和统计等操作都用不上了。知道有这么一种方案就行。

关系型数据库(横表) ： 固定业务字段 + 预留字段 + 元数据

固定的字段(业务字段，系统标识字段)

var1 var2 int1 int2 为预留字段，到底啥意思，需要看元数据怎么描述

 元数据表，示例：

场景：适合固定业务，需要扩展一些信息

优点：实现简单，还在二维表中操作，现有框架都可以用，数据呈现清晰

不足：需要元数据表辅助才可以清楚扩展字段的含义；预留的字段如果没有扩展字段，浪费空间

关系型数据库(横表) ： 固定系统字段 + 预留字段 + 元数据

对上面的更一步抽象，既然元数据能描述字段是啥意思，那么能否将：“客户名称”“客户电话”“客户电话”等业务字段也描述了，答案是可以的。

元数据表：可以看出固定字段重复描述了

不足：如果涉及字段修改，需要刷元数据表（不要小看这个问题，后续解决Bug的时候会是一个负担） 好处：好处是可以对这个字段名称重命名了。

列数据库Hbase

1. 列数据库是按照列来组织数据，适合一次更新：多个学生的，姓名字段。而行数据库适合更新一个学生的多个属性。

2. 列数据库是OLAP(分析)，行数据库是OLTP(事务处理)

3. 列数据库适合在某列上做聚合操作，行数据库适合对一行数据进行操作。

实际业务系统，虽然说列数据库可以节省点空间，但并不适合事务性场景的业务处理；

简单说就是：列数据库可以稍微矮点边，但终究他是为了数据分析设计的， 不适合业务处理数据的存储。

混合方案，举例Salesforce

将数据存储封装为一个服务：包括建表(实体)，表的唯一主键，业务联合主键，字段完整性校验； 将查询单表封装为API，如果可以暴露出来Sql访问就可以了，完全用Sql去DB执行需要熟悉底层表的逻辑，后续成本会指数上升，这指的是，实现了Sql协议的服务。

方案选型

根据Saas平台迭代过程，一般会选择：

关系数据库 --》 关系数据库+sql字段 --》 sql字段如果有统计或者join可以替换为MongoDB

                  --》 固定字段+扩展字段+元数据 --》系统字段+元数据 --》混合型的元数据驱动方案

持久化方案后续问题

1.  持久化方案 要不要独立，独立后要不要 必须规范化，最好能统一查询语言，屏蔽底层逻辑

2.  定位问题，小租户和大数据量租户共存，怎么优化数据

3.  数据量超过kw级别，分表分库的需求。一定会有，日志文件一定会超

参考文档

科学网—面向列的数据库 - 唐李洋的博文