作者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/m.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