表设计遇到一个问题，感觉没有很好的方法

• 请不要在回答技术问题时复制粘贴 AI 生成的内容

This topic created in 2175 days ago, the information mentioned may be changed or developed.

系统存在多种类型的交易，交易的信息绝大部分都是相同的，只有两三个字段不同我目前用了一个交易的主表，其他字段的处理方法我想到两种

1. 可以用 json 存储在主表的一个 other 字段中，但是感觉查询不是很灵活
2. 对不同的交易建立不同的副表，但是每次新增一个交易都要建立副表，表中的字段也很少

这可咋整，json 的没有实际上用过，我不能预测它的副作用。想请有经验的大哥分享下

字段

主表

JSON

交易

24 replies • 2020-06-09 20:08:54 +08:00

HashV2

Jun 9, 2020

加上那两三个字段吧,冗余一点也没关系吧

soulzz

Jun 9, 2020

用 json 存的话会有问题，等你想搜的时候真的蛋疼，单表超过百万后你 like 不出来结果的
最好的办法，用 MongoDb,存的时候直接平铺开，搜的时候好搜，存的时候随便存

likefly

Jun 9, 2020

@HashV2 现存的交易类型有好几种了，每种交易类型都有几个特殊字段，几个交易类型就有十几个冗余字段了

tohert

Jun 9, 2020

就在交易表增加几个扩展字段吧，你这个差别不是很大，只是三两个字段差别

no1xsyzy

Jun 9, 2020

只有两三个字段允许 NULL 就成。NULL 不就是干这事的吗？
交易类型不多且确定但不同的字段比较多就是辅表甚至干脆分表。
交易类型多了或者不确定就转 NoSQL 吧，虽然我还没实际用过，但试了试 ES 在不定型这点还是挺舒服的。

当然还有一种邪道，就是拿一张表当作 RDF 数据库。(relationship, operand1, operand2) 存字符串。
relationship 命名规约类型-字段
('point-x', 'this-point', '10.3')
('point-y', 'this-point', '3.3')
('point-x', 'that-point', '-4.7')
('point-y', 'that-point', '1.1')

Vegetable

Jun 9, 2020

你说的是 Text 还是原生 JSON ？据我所知原生 JSON 在 ORM 这方面还不太成熟。

存文本问题很直观，检索困难。
原生 JSON 的话，除了应用层复杂一些，增加了编码难度，别的我还真想不出来

duwan

Jun 9, 2020

看有没有查询场景，如果有查询场景就加字段建索引，如果没有查询场景就存 json 就行。

duwan

Jun 9, 2020

如果没有查询场景的话基本没有副作用

U97F3

Jun 9, 2020

@duwan #7 交易不可能没有查询场景吧

CHANGEX929

Jun 9, 2020

交易类型这种类似于字典数据的东西，我认为数据量不会很多，所以存 JSON 我觉得是 OK 的。就算全查出来在内存里处理也问题不大

duwan

Jun 9, 2020

@U97F3 我说的查询场景指的是“条件查询”，就是有没有用这个字段当作条件查询的场景。json 适合于存储额外的信息，就是通过其他条件查询能带出来的信息。

colorfulberry

Jun 9, 2020

postgresql 的 jsonb 查询也还可以的。最起码速度还行

ljzxloaf

Jun 9, 2020

别用 json，现在爽，后面一堆问题；用附表的话，多几张表，麻烦一点，可以封装一下，屏蔽掉关联的逻辑；对于交易数据尽量采用追加的方式去记录变更，因为涉及到钱经常要追溯整个交易历史，所以肯定需要很多附表的，不在乎多这几张。

知乎的相关讨论帖： https://www.zhihu.com/question/27607346/answer/116118673

mitu9527

Jun 9, 2020

这种问题其实有好几种设计方式，还是要根据你自己的需求做设计才好。《企业应用架构模式》虽然不是一本讲数据库的书，但是其中单表继承、类表继承和具体表继承、以及序列化 LOB （书里讲的是 XML，你换成 JSON 理解就可以了）都是和你这个问题相关的，看一下各种方案的优缺点，就可以选了。

UnknownR

Jun 9, 2020

json 是让你数据传递的

HashV2

Jun 9, 2020

@likefly 那就一种类型一张表

saulshao

Jun 9, 2020

如果你的交易表中，每种类型的交易多出来的字段不需要大量查询，用纵表是可以的。
如果有针对不一样的字段进行的查询，那么建议还是每种交易类型建立一个横向表。
我以前也觉得表多了不好，但是现在想起来，假设一个对象需要 500 个字段来表达，其实 20 个表，每个表 25 个字段，比一个表包括 500 个字段是要好的。因为无论从功能还是性能来说，扩展起来前者都更容易。