给阔表瘦身的想法

给宽表瘦身的想法
前段要搞个整合不同行业各类优惠活动的系统，其中计算收益的算法，涉及数据非常多
比如酒店入住送积分，连住几天送积分，满额送积分，某端时间积分翻倍，满多少赠多少，入住N天后免费一晚，满多少钱折扣多少钱……
那么计算积分的表里，就需要有积分数，积分类型（倍数还是固定值还是兑换），兑换用的分母，分母类型（房间量、入住时长、会员积分数……），单位，收益重复次数等等等等


而且因为业务关系，不能拆表，但如果使用宽表，一行记录，大部分数据是空的，可读性非常差，数据项有越来越多趋势。
（插一句，我们用的oracle）

针对这类宽表（一行记录中，有效数据并不多），我的解决办法是把需要和其他表做关联的数据项保持不变，而和计算相关的所有字段，用一个大字段代替，数据以json形式保存在大字段内。
原先的设计就变成了 优惠活动ID，业务类型，计算类型，计算数据（4000个字符的大字段）

虽然可读性有些降低（但相比于一行中大段都是空字段，必须来回拉取才能找到所有需要的字段，我觉得可读性反而是提高的）

虽然这个方案乍一看，违背数据库第一泛式，但第一范式并没有规定数据项的拆分，必须以数据基本类型为准；

特别是对于关系型数据库，如果把“基本数据项”，改成和外表关联的维度，和其他表需要进行关联查询的项，都必须符合第一范式；
而仅对本表本条有效的多个数据项，分散为多个或组合成一个，应该以项目需求为准。

比如一段新闻，肯定不会有人把正文按字按符号拆成多个。