作者internetms52 (Oaide)
看板Soft_Job
标题[请益] Database String Array Type
时间Fri Dec 2 19:57:25 2022
各位大大好
小弟是一间小公司里
负责部分核心业务的软体工程师
为了日益多样的客群，被安排要规划新的设计
程式语言使用的是Java,资料库是Postgres
框架使用了Hibernate及Spring data JPA
有天CTO跟我说想到了个好方法
要把核心业务中
原本关系为多对一的A Table 与B Table
改为多对多关系
并把Key直接用String Array Type
储存在A Table的某个新栏位里
这样一来就有很大的弹性
小弟做了一些功课
向CTO表达了应该加关系表正规化的想法
但CTO不满意，觉得关系表很多余
小弟又用String Array Type 在Java世界里
并没有完整支援为理由尝试说服
CTO却觉得这些都是可以克服的问题...
小弟认为一但使用String Array Type
并且不使用关系表
就很有可能要全部走Native SQL
日後无论延展需求或维护都会相当痛苦
为此非常苦恼
因为核心业务的复杂程度
小弟希望可以降低日後的维护门槛
想询问各位大大
String Array Type的问题
真的有这麽好克服吗？
或是有什麽更好的说服理由是小弟没想到的？
这是小弟首次於软体版发文
感谢耐心看完的大大们，献上万分的谢意
----
Sent from
BePTT on my Samsung SM-A528B
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 42.70.45.29 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1669982247.A.465.html
1F：推 chuegou: 我的建议是不要怕留下技术债 还债的不一定是你 12/02 20:23
2F：推 chen09885: 实际上正规化後各种限制也是问题 12/02 20:51
3F：推 abccbaandy: 推1F，怕什麽，你这专案成功了就丢给菜鸟维护了 12/02 21:13
4F：→ abccbaandy: 还能嘴他需求做太慢，你当年XX一天就好 12/02 21:14
5F：推 CRPKT: 你们业务逻辑里有没有需要从 B 反查 A? 12/02 21:20
6F：→ internetms52: CRPKT大大您好，主要的逻辑都是从B向A来查询的，是 12/02 21:37
7F：→ internetms52: 为了多个B对多个A才这样做的，因为1B对多A的关系不 12/02 21:37
8F：→ internetms52: 够用 12/02 21:37
9F：→ neo5277: 存json字串 或是乾脆nosql 12/02 22:08
10F：推 jack0204: 关系表是有必要的，也可以用NOSQL，或是快逃 12/02 23:01
11F：推 jack0204: 不过根据主要业务来评估比较好，如果不频繁的话都行 12/02 23:07
12F：推 SHANGOYANYI: 需要这麽厚工喔？ 一个基本多对多的表是难在哪?XD 12/03 00:37
13F：→ alan3100: 不就一个mapping table就搞定是难在哪 12/03 01:05
14F：→ alan3100: pk:id,A_pk,B_pk,isValid,modifyDate 12/03 01:09
15F：→ alan3100: string array或nosql 你都还是要面对是否要强一致性问题 12/03 01:11
16F：→ ssccg: 你是要问怎样比较好，还是怎麽说服你家CTO.. 12/03 01:37
17F：→ ssccg: 如果要表达关系的话，关系表才是最简单又有弹性的，存个 12/03 01:46
18F：→ ssccg: array除了不开新table外，既没好处也没什麽很大的弹性啊 12/03 01:47
19F：→ internetms52: CTO的沟通部分也许跟软体不太有关，若觉得奇怪就留 12/03 07:16
20F：→ internetms52: 给小弟我自己解决就可以了，大大们就分享想分享的 12/03 07:16
21F：→ internetms52: 部分就好，谢谢各位大大的回覆 12/03 07:16
22F：推 Jichang: 有些情况是不太想用 join 两种方法各有优缺 有json type 12/03 08:15
23F：→ Jichang: 可以用 12/03 08:15
24F：→ brucetu: 读写比例 预估资料总笔数 峰值流量 日常流量 12/03 12:35
25F：→ brucetu: 这些都会影响你要用哪种方式实作 12/03 12:36
26F：→ brucetu: 但有一个很简单的准则就是 如果你小公司 流量小 12/03 12:36
27F：→ brucetu: 就用写code最快的方式让memory去扛一切的问题 12/03 12:36
28F：→ brucetu: 你家CTO提出的办法基本上就是写code最快最懒的方法 12/03 12:38
29F：→ brucetu: 也就是最省成本 12/03 12:38
30F：→ brucetu: 建议你就做 万一效能爆炸 增加硬体成本 责任不在你 12/03 12:39
31F：推 SHANGOYANYI: 真的照你家CTO那想法做 那以後资料层问题是dev负责 12/03 13:24
32F：→ SHANGOYANYI: 还是dba负责？ 12/03 13:24
33F：→ Firstshadow: 这种可以当CTO==? 12/03 13:51
34F：→ HKCs: 用json/jsonb吧 反正他提出来的 出事就叫他自己去跟老板/客 12/03 14:22
35F：→ HKCs: 户解释 12/03 14:22
36F：推 OriginStar: stackoverflow也有人问类似的问题，也有人提出解决 12/03 14:37
37F：→ OriginStar: 方法，所以技术上不是问题，CTO则是考量公司营运未来 12/03 14:38
38F：→ OriginStar: 所以所预先的规划，即使原PO不做也会找别人做，当然 12/03 14:40
39F：→ OriginStar: 原PO不在意升迁、加薪、年终的话说自己不想负责这块 12/03 14:41
40F：→ OriginStar: 看能不能请其他同事负责也行 12/03 14:41
41F：推 s06yji3: 又不是什麽违背良心的事情XD 12/03 14:52
42F：推 hobnob: CTO不都是自家公司随便喊的吗。原PO就照做就好，不必争论 12/03 17:18
43F：→ hobnob: ，未来自己当CTO之後就可以做借镜了 12/03 17:18
44F：推 marc47: 如果只有几十万笔资料，爱怎麽变就让他变，如果是几千万笔 12/04 00:45
45F：→ marc47: 以上，要三思，pg的sql analyze很笨，更何况还要用array去 12/04 00:45
46F：→ marc47: 拆，及做关联，explain你看看cost可能都是full table scan 12/04 00:45
47F：→ marc47: ，cost可能就吓死人 12/04 00:45
48F：→ ssccg: 那方法怎麽会写code最快最懒，原po都说了用jpa hibernate 12/04 03:53
49F：→ ssccg: 关系表直接@ManyToMany就完了，array一定要用postgres的 12/04 03:54
50F：→ ssccg: native sql去写，哪里省了 12/04 03:54
51F：→ ssccg: 好像有不少人包括一楼说技术债都以为是在说CTO提了个方便快 12/04 03:59
52F：→ ssccg: 速的方法，不是吧这篇明明是在抱怨CTO提了个程式就比较难写 12/04 03:59
53F：→ ssccg: 又不合常规、但也说不出哪里好(只说就有很大的弹性、关系表 12/04 04:00
54F：→ ssccg: 多余)，然後也没什麽目的只为了少开个多余(?)table 12/04 04:01
55F：→ ssccg: 当然实际上也许CTO是有什麽考量，但显然原PO没接收到 12/04 04:03
56F：嘘 pttano: 可怜喔，烂CTO搭配junior ，真是一绝 12/04 09:44
57F：推 ppc: 一楼精辟 12/04 13:47
58F：→ superpandal: 一楼三楼是在自爆自己的为人吗? XD 不过一堆没讲的都 12/05 18:50
59F：→ superpandal: 是这样 环境真的不好 12/05 18:50
60F：→ superpandal: 言归正传 解法楼上都有人说了 用json postgres可提取 12/05 18:56
61F：→ superpandal: json内的值 或者你取出来反序列化也可以 如果了解 12/05 18:58
62F：→ superpandal: json本质 会觉得这格式很不错 12/05 18:59
63F：→ superpandal: postgres有一些json_为前缀的函数 12/05 19:02
64F：推 come: 资料量不大或者存取不频繁就会以可维护性来考量。 12/05 22:22
65F：→ come: 或者说追求一致。但是一旦资料量大，就要考虑join成本。 12/05 22:23
66F：→ come: 这个时候就会认真考虑用json了 12/05 22:24
67F：→ come: jsonb是解multi-value的好工具 12/05 22:24
68F：推 answermangtr: CTO CIO多的是 不是技术出身的咖 看多了啦 12/06 00:38
69F：推 Killercat: 问他为啥要过度设计 有没有有潜在的需求 12/08 08:00
70F：→ Killercat: 会不会沟通这些东西往往就是junior senior的差别 12/08 08:01
71F：推 BigCockman: 还好吧 反正规化的一种而已 做正规化不等於比较好维 12/08 10:53
72F：→ BigCockman: 护跟扩展 坦白说硬要正规化是有点过时的想法了 12/08 10:53
73F：→ superpandal: 这不是过度设计 是实作方式不同 一致性与灵活性是可 12/08 19:41
74F：→ superpandal: 以兼得的 但市面上多半都是看到一致性强但改个小功能 12/08 19:42
75F：→ superpandal: 就很累的东西 12/08 19:43
76F：→ superpandal: 框架会加强一致性但也会缩限应用 巨无霸框架是灾难 12/08 19:46