[請益] Database String Array Type

看板Soft_Job作者 (Oaide)時間1年前 (2022/12/02 19:57), 編輯推噓15(16推 1噓 51→)
留言68則, 23人參與, 1年前最新討論串1/1
各位大大好 小弟是一間小公司裡 負責部分核心業務的軟體工程師 為了日益多樣的客群，被安排要規劃新的設計 程式語言使用的是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://www.ptt.cc/bbs/Soft_Job/M.1669982247.A.465.html
推
12/02 20:23, 1年前 , 1F
我的建議是不要怕留下技術債 還債的不一定是你
12/02 20:23, 1F
推
12/02 20:51, 1年前 , 2F
實際上正規化後各種限制也是問題
12/02 20:51, 2F
推
12/02 21:13, 1年前 , 3F
推1F，怕什麼，你這專案成功了就丟給菜鳥維護了
12/02 21:13, 3F
→
12/02 21:14, 1年前 , 4F
還能嘴他需求做太慢，你當年XX一天就好
12/02 21:14, 4F
推
12/02 21:20, 1年前 , 5F
你們業務邏輯裡有沒有需要從 B 反查 A?
12/02 21:20, 5F
→
12/02 21:37, 1年前 , 6F
CRPKT大大您好，主要的邏輯都是從B向A來查詢的，是
12/02 21:37, 6F
→
12/02 21:37, 1年前 , 7F
為了多個B對多個A才這樣做的，因為1B對多A的關係不
12/02 21:37, 7F
→
12/02 21:37, 1年前 , 8F
夠用
12/02 21:37, 8F
→
12/02 22:08, 1年前 , 9F
存json字串 或是乾脆nosql
12/02 22:08, 9F
推
12/02 23:01, 1年前 , 10F
關係表是有必要的，也可以用NOSQL，或是快逃
12/02 23:01, 10F
推
12/02 23:07, 1年前 , 11F
不過根據主要業務來評估比較好，如果不頻繁的話都行
12/02 23:07, 11F
推
12/03 00:37, 1年前 , 12F
需要這麼厚工喔？ 一個基本多對多的表是難在哪?XD
12/03 00:37, 12F
→
12/03 01:05, 1年前 , 13F
不就一個mapping table就搞定是難在哪
12/03 01:05, 13F
→
12/03 01:09, 1年前 , 14F
pk:id,A_pk,B_pk,isValid,modifyDate
12/03 01:09, 14F
→
12/03 01:11, 1年前 , 15F
string array或nosql 你都還是要面對是否要強一致性問題
12/03 01:11, 15F
→
12/03 01:37, 1年前 , 16F
你是要問怎樣比較好，還是怎麼說服你家CTO..
12/03 01:37, 16F
→
12/03 01:46, 1年前 , 17F
如果要表達關係的話，關係表才是最簡單又有彈性的，存個
12/03 01:46, 17F
→
12/03 01:47, 1年前 , 18F
array除了不開新table外，既沒好處也沒什麼很大的彈性啊
12/03 01:47, 18F
→
12/03 07:16, 1年前 , 19F
CTO的溝通部分也許跟軟體不太有關，若覺得奇怪就留
12/03 07:16, 19F
→
12/03 07:16, 1年前 , 20F
給小弟我自己解決就可以了，大大們就分享想分享的
12/03 07:16, 20F
→
12/03 07:16, 1年前 , 21F
部分就好，謝謝各位大大的回覆
12/03 07:16, 21F
推
12/03 08:15, 1年前 , 22F
有些情況是不太想用 join 兩種方法各有優缺 有json type
12/03 08:15, 22F
→
12/03 08:15, 1年前 , 23F
可以用
12/03 08:15, 23F
→
12/03 12:35, 1年前 , 24F
讀寫比例 預估資料總筆數 峰值流量 日常流量
12/03 12:35, 24F
→
12/03 12:36, 1年前 , 25F
這些都會影響你要用哪種方式實作
12/03 12:36, 25F
→
12/03 12:36, 1年前 , 26F
但有一個很簡單的準則就是 如果你小公司 流量小
12/03 12:36, 26F
→
12/03 12:36, 1年前 , 27F
就用寫code最快的方式讓memory去扛一切的問題
12/03 12:36, 27F
→
12/03 12:38, 1年前 , 28F
你家CTO提出的辦法基本上就是寫code最快最懶的方法
12/03 12:38, 28F
→
12/03 12:38, 1年前 , 29F
也就是最省成本
12/03 12:38, 29F
→
12/03 12:39, 1年前 , 30F
建議你就做 萬一效能爆炸 增加硬體成本 責任不在你
12/03 12:39, 30F
推
12/03 13:24, 1年前 , 31F
真的照你家CTO那想法做 那以後資料層問題是dev負責
12/03 13:24, 31F
→
12/03 13:24, 1年前 , 32F
還是dba負責？
12/03 13:24, 32F
→
12/03 13:51, 1年前 , 33F
這種可以當CTO==?
12/03 13:51, 33F
→
12/03 14:22, 1年前 , 34F
用json/jsonb吧 反正他提出來的 出事就叫他自己去跟老闆/客
12/03 14:22, 34F
→
12/03 14:22, 1年前 , 35F
戶解釋
12/03 14:22, 35F
推
12/03 14:37, 1年前 , 36F
stackoverflow也有人問類似的問題，也有人提出解決
12/03 14:37, 36F
→
12/03 14:38, 1年前 , 37F
方法，所以技術上不是問題，CTO則是考量公司營運未來
12/03 14:38, 37F
→
12/03 14:40, 1年前 , 38F
所以所預先的規劃，即使原PO不做也會找別人做，當然
12/03 14:40, 38F
→
12/03 14:41, 1年前 , 39F
原PO不在意升遷、加薪、年終的話說自己不想負責這塊
12/03 14:41, 39F
→
12/03 14:41, 1年前 , 40F
看能不能請其他同事負責也行
12/03 14:41, 40F
推
12/03 14:52, 1年前 , 41F
又不是什麼違背良心的事情XD
12/03 14:52, 41F
推
12/03 17:18, 1年前 , 42F
CTO不都是自家公司隨便喊的嗎。原PO就照做就好，不必爭論
12/03 17:18, 42F
→
12/03 17:18, 1年前 , 43F
，未來自己當CTO之後就可以做借鏡了
12/03 17:18, 43F
推
12/04 00:45, 1年前 , 44F
如果只有幾十萬筆資料，愛怎麼變就讓他變，如果是幾千萬筆
12/04 00:45, 44F
→
12/04 00:45, 1年前 , 45F
以上，要三思，pg的sql analyze很笨，更何況還要用array去
12/04 00:45, 45F
→
12/04 00:45, 1年前 , 46F
拆，及做關聯，explain你看看cost可能都是full table scan
12/04 00:45, 46F
→
12/04 00:45, 1年前 , 47F
，cost可能就嚇死人
12/04 00:45, 47F
→
12/04 03:53, 1年前 , 48F
那方法怎麼會寫code最快最懶，原po都說了用jpa hibernate
12/04 03:53, 48F
→
12/04 03:54, 1年前 , 49F
關係表直接@ManyToMany就完了，array一定要用postgres的
12/04 03:54, 49F
→
12/04 03:54, 1年前 , 50F
native sql去寫，哪裡省了
12/04 03:54, 50F
→
12/04 03:59, 1年前 , 51F
好像有不少人包括一樓說技術債都以為是在說CTO提了個方便快
12/04 03:59, 51F
→
12/04 03:59, 1年前 , 52F
速的方法，不是吧這篇明明是在抱怨CTO提了個程式就比較難寫
12/04 03:59, 52F
→
12/04 04:00, 1年前 , 53F
又不合常規、但也說不出哪裡好(只說就有很大的彈性、關係表
12/04 04:00, 53F
→
12/04 04:01, 1年前 , 54F
多餘)，然後也沒什麼目的只為了少開個多餘(?)table
12/04 04:01, 54F
→
12/04 04:03, 1年前 , 55F
當然實際上也許CTO是有什麼考量，但顯然原PO沒接收到
12/04 04:03, 55F
噓
12/04 09:44, 1年前 , 56F
可憐喔，爛CTO搭配junior ，真是一絕
12/04 09:44, 56F
推
12/04 13:47, 1年前 , 57F
一樓精闢
12/04 13:47, 57F
→
12/05 18:50, 1年前 , 58F
一樓三樓是在自爆自己的為人嗎? XD 不過一堆沒講的都
12/05 18:50, 58F
→
12/05 18:50, 1年前 , 59F
是這樣 環境真的不好
12/05 18:50, 59F
→
12/05 18:56, 1年前 , 60F
言歸正傳 解法樓上都有人說了 用json postgres可提取
12/05 18:56, 60F
→
12/05 18:58, 1年前 , 61F
json內的值 或者你取出來反序列化也可以 如果了解
12/05 18:58, 61F
→
12/05 18:59, 1年前 , 62F
json本質 會覺得這格式很不錯
12/05 18:59, 62F
→
12/05 19:02, 1年前 , 63F
postgres有一些json_為前綴的函數
12/05 19:02, 63F
推
12/05 22:22, 1年前 , 64F
資料量不大或者存取不頻繁就會以可維護性來考量。
12/05 22:22, 64F
→
12/05 22:23, 1年前 , 65F
或者說追求一致。但是一旦資料量大，就要考慮join成本。
12/05 22:23, 65F
→
12/05 22:24, 1年前 , 66F
這個時候就會認真考慮用json了
12/05 22:24, 66F
→
12/05 22:24, 1年前 , 67F
jsonb是解multi-value的好工具
12/05 22:24, 67F
推
12/06 00:38, 1年前 , 68F
CTO CIO多的是 不是技術出身的咖 看多了啦
12/06 00:38, 68F
‣ 更多 internetms52 的文章
文章代碼(AID): #1ZYUWdHb (Soft_Job)