使用 Eav 模型构建可无限扩展的数据存储能力

举个例子

假设要做一个电商的商品管理，我们先卖一些衣服，需要管理衣服的尺码、颜色、款式等信息，有一天需要卖电脑了，电脑需要 主板、CPU、显卡、内存、硬盘、散热 等信息，过几天又需要卖手机了，手机有 颜色、版本、存储容量、套餐类型等等信息，数据库如何设计。

方案一：新增字段

每次新增商品，需要支持不同的信息的话就不停的加字段。

ID	Name	尺码	颜色	款式	主板	CPU	显卡	内存	存储	散热	版本	套餐类型
1	T恤	M	白色	喜羊羊	NULL	NULL	NULL	NULL	NULL	NULL	NULL	NULL
2	外星人电脑	NULL	NULL	NULL	A	i99	RTX8090	32G	2T	水冷	NULL	键鼠套装
3	香蕉手机	NULL	五彩斑斓黑	NULL	NULL	晓龙999	NULL	12G	512G	风扇	Pro Plus MAX	碎屏险套餐

这样会造成以下问题：

1. 实现成本高，每次添加商品都需要进行前后端开发、调试，浪费时间和人力。
2. 需要动态变更表结构，在生产环境中安全性太低。
3. 浪费资源，数据库的字段可能会越来越多，而很多字段大部分商品都是不需要的，需要设置为NULL，导致内存大量浪费。
4. 扩展能力一般，有上限。

方案二：预留字段

给对应的表定义几个预留字段，然后这些预留字段在不同的商品可以重复使用。这样的话可以解决一部分的开发问题，大部分情况不需要开发，直接复用现有字段就可以。

ID	Name	Ext1	Ext2	Ext3	Ext4	Ext5	Ext6	Ext7
1	T恤	M	白色	喜羊羊	NULL	NULL	NULL	NULL
2	外星人电脑	A	i99	RTX8090	32G	2T	水冷	键鼠套装
3	香蕉手机	五彩斑斓黑	晓龙999	12G	512G	风扇	Pro Plus MAX	碎屏险套餐

但是这样也有很多问题：

1. 字段一样，但是含义不一样，需要前端做大量适配。
2. 字段的类型可能不一样，预留字段还得考虑不同的类型。
3. 预留字段太少了作用有限，太多了和新增字段一样会有存储和性能问题。
4. 扩展字段是公用的，不能根据字段名顾名思义，得在启用时维护对应关系，使用时查找对应关系。
5. 扩展字段的数量无法精确定义。

方案三：JSON_OBJECT

这种情况下有一种简单的解决方案，就是设计一个 extra 字段，类型为 JSON，然后把 尺码、颜色、款色、主板、CPU、显卡、内存等等都放到 JSON 里。

ID	Name	Ext1
1	T恤	{ "尺码": "M", "颜色": "白色", "款式": "喜羊羊" }
2	外星人电脑	{ "主板": "A", "CPU": "i9 11900", "显卡": "RTX8090", "内存": "32G", "存储": "2