这是一个创建于 1665 天前的主题，其中的信息可能已经有所发展或是发生改变。
系统存在多种类型的交易，交易的信息绝大部分都是相同的，只有两三个字段不同 我目前用了一个交易的主表，其他字段的处理方法我想到两种
1. 可以用 json 存储在主表的一个 other 字段中，但是感觉查询不是很灵活
2. 对不同的交易建立不同的副表，但是每次新增一个交易都要建立副表，表中的字段也很少
这可咋整，json 的没有实际上用过，我不能预测它的副作用。想请有经验的大哥分享下
 |
1
HashV2 2020-06-09 09:31:51 +08:00
加上那两三个字段吧,冗余一点也没关系吧
|
 |
2
soulzz 2020-06-09 09:36:06 +08:00
用 json 存的话会有问题，等你想搜的时候真的蛋疼，单表超过百万后你 like 不出来结果的
最好的办法，用 MongoDb,存的时候直接平铺开，搜的时候好搜，存的时候随便存 |
 |
4
tohert 2020-06-09 09:49:37 +08:00
就在交易表增加几个扩展字段吧， 你这个差别不是很大，只是三两个字段差别
|
 |
5
no1xsyzy 2020-06-09 09:53:37 +08:00  1
只有两三个字段允许 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') |
 |
6
Vegetable 2020-06-09 09:56:17 +08:00
你说的是 Text 还是原生 JSON ？据我所知原生 JSON 在 ORM 这方面还不太成熟。
存文本问题很直观，检索困难。 原生 JSON 的话，除了应用层复杂一些，增加了编码难度，别的我还真想不出来 |
 |
7
duwan 2020-06-09 10:07:39 +08:00
看有没有查询场景，如果有查询场景就加字段建索引，如果没有查询场景就存 json 就行。
|
|
8
duwan 2020-06-09 10:08:39 +08:00
如果没有查询场景的话 基本没有副作用
|
 |
10
CHANGEX929 2020-06-09 10:46:51 +08:00
交易类型 这种类似于字典数据的东西，我认为数据量不会很多，所以存 JSON 我觉得是 OK 的。就算全查出来在内存里处理也问题不大
|
|
11
duwan 2020-06-09 11:00:01 +08:00
@U97F3 我说的查询场景指的是“条件查询”，就是有没有用这个字段当作条件查询的场景。json 适合于存储额外的信息，就是通过其他条件查询能带出来的信息。
|
 |
12
colorfulberry 2020-06-09 11:05:29 +08:00
postgresql 的 jsonb 查询也还可以的。最起码速度还行
|
 |
13
ljzxloaf 2020-06-09 11:06:46 +08:00
别用 json，现在爽，后面一堆问题；用附表的话，多几张表，麻烦一点，可以封装一下，屏蔽掉关联的逻辑；对于交易数据尽量采用追加的方式去记录变更，因为涉及到钱经常要追溯整个交易历史，所以肯定需要很多附表的，不在乎多这几张。
知乎的相关讨论帖： https://www.zhihu.com/question/27607346/answer/116118673 |
 |
14
mitu9527 2020-06-09 11:07:55 +08:00
这种问题其实有好几种设计方式，还是要根据你自己的需求做设计才好。《企业应用架构模式》虽然不是一本讲数据库的书，但是其中单表继承、类表继承和具体表继承、以及序列化 LOB （书里讲的是 XML，你换成 JSON 理解就可以了）都是和你这个问题相关的，看一下各种方案的优缺点，就可以选了。
|
 |
15
UnknownR 2020-06-09 11:29:16 +08:00
json 是让你数据传递的
|
 |
17
saulshao 2020-06-09 15:01:56 +08:00
如果你的交易表中，每种类型的交易多出来的字段不需要大量查询，用纵表是可以的。
如果有针对不一样的字段进行的查询，那么建议还是每种交易类型建立一个横向表。 我以前也觉得表多了不好，但是现在想起来，假设一个对象需要 500 个字段来表达，其实 20 个表，每个表 25 个字段，比一个表包括 500 个字段是要好的。因为无论从功能还是性能来说，扩展起来前者都更容易。 |
 |
18
ppphp 2020-06-09 15:20:43 +08:00
json 需要搜索的话建议加一列 type 或者再开一张表,json 格式的数据不方便用 Sql 语言处理，尽量在 sql 里做 sql 能做的事情，不然数据结构很容易乱
|
 |
19
inktiger 2020-06-09 17:19:04 +08:00
我觉得附表挺好的哇，这种情况我肯定用附表，方便现在储存，方便查询，甚至以后如果数据量大了分表什么的也贼方便
|
 |
20
xuanbg 2020-06-09 17:23:55 +08:00
不做条件查询的话用 json，查出来直接就是对象，非常方便。
|
 |
21
akira 2020-06-09 18:22:10 +08:00
附加信息字段 1
附加信息字段 2 附加信息字段 3 |
 |
22
superrichman 2020-06-09 18:25:37 +08:00 via iPhone
快醒醒，数据库存 json 后期会被打死的 /doge
|
 |
23
siweipancc 2020-06-09 19:29:48 +08:00 via iPhone
:D json 后期全是慢查询
|
 |
24
Xbluer 2020-06-09 20:08:54 +08:00 via iPhone
把差异的字段用 key value 的方式保存在单独的表中。不过 value 如果有多种数据类型就需要处理下了。
|
Select Language