系统是买来的,原来只有 a (主信息)表和 b (扩展信息)表,表示一个金融产品
a 表
|id |name |price|des1|des2|
|1 |基金 A|1.2 |按月|每日|
|2 |基金 B|1.3 |按月|每月|
这一切都是为了生成合同填充, desx 表示描述字段,例如:
${name}价格为${price} ,赎回方式为${des1},${des2}计算份额……
后来随着产品的增多,噩梦开始了,因为描述性的字段越来越多,而且是不同类型的,表开始编程这样
|id |name|price|des1|des2|des3|des4|
|----|----|-----|----|----|----|----|
|1 |基金 A|1.2 |按月|每日|null|null|
|2 |基金 B|1.3 |按月|每月|null|null|
|3 |股票 A|1.3 |null|null|深市|3:00|
类似这种,就是不断添加 column 来保存不同类型的合同的信息,而用不到的字段空着,每个类型都不重复 也就是不定数量的描述字段,现在每次加这些都要增加 column ,非常痛苦,所以想优化下
方案 1 :将所有的额外描述信息存成 json ,解析存储,但是可能更新会有麻烦 方案 2 :将每个字段拆分,拆成产品和字段对应表,以及字段和值的对应表,最后列转行显示 方案 3 :用无意义字段新建一张表,和上面同样结构,只不过字段为 field1 , field2 ……建立文档来维护,每个产品的 field1 表示什么意思
感觉三种都不是很好,希望大家能提供个设计的思路,谢谢
1
micyng 2016-08-08 22:58:42 +08:00
mongo
|
2
loading 2016-08-08 23:46:08 +08:00 via Android
存 xml 或 json 到一个字段。
随便加 |
3
flyingghost 2016-08-09 10:47:11 +08:00
如果只显示, json 可也。
如果经常维护,方案 2 。 如果不限于关系型数据库, mongo 好。 |
4
SmiteChow 2016-08-09 10:54:06 +08:00
你需要的是 generic relation
generic table: object_id, object_type, title, value, |
5
ihuotui 2016-08-13 21:55:23 +08:00 via Android
eav 的表, but 就是操作麻烦,合理划分子表吧。
|