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

[likefly]

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

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

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

[HashV2]

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

[soulzz]

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

[likefly]

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

[tohert]

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

[no1xsyzy]

只有两三个字段允许 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]

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

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

[duwan]

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

[duwan]

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

[U97F3]

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

[CHANGEX929]

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

[duwan]

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

[colorfulberry]

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

[ljzxloaf]

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

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

[mitu9527]

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

[UnknownR]

json 是让你数据传递的

[HashV2]

@likefly 那就一种类型一张表

[saulshao]

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

[ppphp]

json 需要搜索的话建议加一列 type 或者再开一张表,json 格式的数据不方便用 Sql 语言处理，尽量在 sql 里做 sql 能做的事情，不然数据结构很容易乱

[inktiger]

我觉得附表挺好的哇，这种情况我肯定用附表，方便现在储存，方便查询，甚至以后如果数据量大了分表什么的也贼方便

[xuanbg]

不做条件查询的话用 json，查出来直接就是对象，非常方便。

[akira]

附加信息字段 1
附加信息字段 2
附加信息字段 3

[superrichman]

快醒醒，数据库存 json 后期会被打死的 /doge

[siweipancc]

:D json 后期全是慢查询

[Xbluer]

把差异的字段用 key value 的方式保存在单独的表中。不过 value 如果有多种数据类型就需要处理下了。