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中数据的缓存来查询，冗余了数据但兼容了有点
缺点：数据一致性保障，对开发和框架有要求
关系型数据库(纵表)
什么是纵表
- 属性值 依赖 某个品类的某个对象(对象ID)的 某个属性值(属性ID)，且某个对象的属性值可变，又没法记录，但属性值在某时刻或者某时间段(时间区间)是固定值，所以才可记录
- “是否当前有效”标识是否是 对象的当前(现在)的属性值
- “是否有效”标识 该数据是否有用，可能是错误数据，删除了，没用了。
没有优点和不足
只是一种方案，这么存储数据效率太低了。看也不好看， 查询和统计等操作都用不上了。知道有这么一种方案就行。
关系型数据库(横表) ： 固定业务字段 + 预留字段 + 元数据
固定的字段(业务字段，系统标识字段)
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级别，分表分库的需求。一定会有，日志文件一定会超
参考文档
科学网—面向列的数据库 - 唐李洋的博文