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

2020-06-09 09:28:30 +08:00
 likefly

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

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

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

2944 次点击
所在节点    程序员
24 条回复
HashV2
2020-06-09 09:31:51 +08:00
加上那两三个字段吧,冗余一点也没关系吧
soulzz
2020-06-09 09:36:06 +08:00
用 json 存的话会有问题,等你想搜的时候真的蛋疼,单表超过百万后你 like 不出来结果的
最好的办法,用 MongoDb,存的时候直接平铺开,搜的时候好搜,存的时候随便存
likefly
2020-06-09 09:47:10 +08:00
@HashV2 现存的交易类型有好几种了,每种交易类型都有几个特殊字段,几个交易类型就有十几个冗余字段了
tohert
2020-06-09 09:49:37 +08:00
就在交易表增加几个扩展字段吧, 你这个差别不是很大,只是三两个字段差别
no1xsyzy
2020-06-09 09:53:37 +08:00
只有两三个字段允许 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
2020-06-09 09:56:17 +08:00
你说的是 Text 还是原生 JSON ?据我所知原生 JSON 在 ORM 这方面还不太成熟。

存文本问题很直观,检索困难。
原生 JSON 的话,除了应用层复杂一些,增加了编码难度,别的我还真想不出来
duwan
2020-06-09 10:07:39 +08:00
看有没有查询场景,如果有查询场景就加字段建索引,如果没有查询场景就存 json 就行。
duwan
2020-06-09 10:08:39 +08:00
如果没有查询场景的话 基本没有副作用
U97F3
2020-06-09 10:36:25 +08:00
@duwan #7 交易不可能没有查询场景吧
CHANGEX929
2020-06-09 10:46:51 +08:00
交易类型 这种类似于字典数据的东西,我认为数据量不会很多,所以存 JSON 我觉得是 OK 的。就算全查出来在内存里处理也问题不大
duwan
2020-06-09 11:00:01 +08:00
@U97F3 我说的查询场景指的是“条件查询”,就是有没有用这个字段当作条件查询的场景。json 适合于存储额外的信息,就是通过其他条件查询能带出来的信息。
colorfulberry
2020-06-09 11:05:29 +08:00
postgresql 的 jsonb 查询也还可以的。最起码速度还行
ljzxloaf
2020-06-09 11:06:46 +08:00
别用 json,现在爽,后面一堆问题;用附表的话,多几张表,麻烦一点,可以封装一下,屏蔽掉关联的逻辑;对于交易数据尽量采用追加的方式去记录变更,因为涉及到钱经常要追溯整个交易历史,所以肯定需要很多附表的,不在乎多这几张。

知乎的相关讨论帖: https://www.zhihu.com/question/27607346/answer/116118673
mitu9527
2020-06-09 11:07:55 +08:00
这种问题其实有好几种设计方式,还是要根据你自己的需求做设计才好。《企业应用架构模式》虽然不是一本讲数据库的书,但是其中单表继承、类表继承和具体表继承、以及序列化 LOB (书里讲的是 XML,你换成 JSON 理解就可以了)都是和你这个问题相关的,看一下各种方案的优缺点,就可以选了。
UnknownR
2020-06-09 11:29:16 +08:00
json 是让你数据传递的
HashV2
2020-06-09 13:51:57 +08:00
@likefly 那就一种类型一张表
saulshao
2020-06-09 15:01:56 +08:00
如果你的交易表中,每种类型的交易多出来的字段不需要大量查询,用纵表是可以的。
如果有针对不一样的字段进行的查询,那么建议还是每种交易类型建立一个横向表。
我以前也觉得表多了不好,但是现在想起来,假设一个对象需要 500 个字段来表达,其实 20 个表,每个表 25 个字段,比一个表包括 500 个字段是要好的。因为无论从功能还是性能来说,扩展起来前者都更容易。
ppphp
2020-06-09 15:20:43 +08:00
json 需要搜索的话建议加一列 type 或者再开一张表,json 格式的数据不方便用 Sql 语言处理,尽量在 sql 里做 sql 能做的事情,不然数据结构很容易乱
inktiger
2020-06-09 17:19:04 +08:00
我觉得附表挺好的哇,这种情况我肯定用附表,方便现在储存,方便查询,甚至以后如果数据量大了分表什么的也贼方便
xuanbg
2020-06-09 17:23:55 +08:00
不做条件查询的话用 json,查出来直接就是对象,非常方便。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/679875

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX