推 chuegou: 我的建議是不要怕留下技術債 還債的不一定是你 12/02 20:23
推 chen09885: 實際上正規化後各種限制也是問題 12/02 20:51
推 abccbaandy: 推1F，怕什麼，你這專案成功了就丟給菜鳥維護了 12/02 21:13
→ abccbaandy: 還能嘴他需求做太慢，你當年XX一天就好 12/02 21:14
推 CRPKT: 你們業務邏輯裡有沒有需要從 B 反查 A? 12/02 21:20
→ internetms52: CRPKT大大您好，主要的邏輯都是從B向A來查詢的，是 12/02 21:37
→ internetms52: 為了多個B對多個A才這樣做的，因為1B對多A的關係不 12/02 21:37
→ internetms52: 夠用 12/02 21:37
→ neo5277: 存json字串 或是乾脆nosql 12/02 22:08
推 jack0204: 關係表是有必要的，也可以用NOSQL，或是快逃 12/02 23:01
推 jack0204: 不過根據主要業務來評估比較好，如果不頻繁的話都行 12/02 23:07
推 SHANGOYANYI: 需要這麼厚工喔？ 一個基本多對多的表是難在哪?XD 12/03 00:37
→ alan3100: 不就一個mapping table就搞定是難在哪 12/03 01:05
→ alan3100: pk:id,A_pk,B_pk,isValid,modifyDate 12/03 01:09
→ alan3100: string array或nosql 你都還是要面對是否要強一致性問題 12/03 01:11
→ ssccg: 你是要問怎樣比較好，還是怎麼說服你家CTO.. 12/03 01:37
→ ssccg: 如果要表達關係的話，關係表才是最簡單又有彈性的，存個 12/03 01:46
→ ssccg: array除了不開新table外，既沒好處也沒什麼很大的彈性啊 12/03 01:47
→ internetms52: CTO的溝通部分也許跟軟體不太有關，若覺得奇怪就留 12/03 07:16
→ internetms52: 給小弟我自己解決就可以了，大大們就分享想分享的 12/03 07:16
→ internetms52: 部分就好，謝謝各位大大的回覆 12/03 07:16
推 Jichang: 有些情況是不太想用 join 兩種方法各有優缺 有json type 12/03 08:15
→ Jichang: 可以用 12/03 08:15
→ brucetu: 讀寫比例 預估資料總筆數 峰值流量 日常流量 12/03 12:35
→ brucetu: 這些都會影響你要用哪種方式實作 12/03 12:36
→ brucetu: 但有一個很簡單的準則就是 如果你小公司 流量小 12/03 12:36
→ brucetu: 就用寫code最快的方式讓memory去扛一切的問題 12/03 12:36
→ brucetu: 你家CTO提出的辦法基本上就是寫code最快最懶的方法 12/03 12:38
→ brucetu: 也就是最省成本 12/03 12:38
→ brucetu: 建議你就做 萬一效能爆炸 增加硬體成本 責任不在你 12/03 12:39
推 SHANGOYANYI: 真的照你家CTO那想法做 那以後資料層問題是dev負責 12/03 13:24
→ SHANGOYANYI: 還是dba負責？ 12/03 13:24
→ Firstshadow: 這種可以當CTO==? 12/03 13:51
→ HKCs: 用json/jsonb吧 反正他提出來的 出事就叫他自己去跟老闆/客 12/03 14:22
→ HKCs: 戶解釋 12/03 14:22
推 OriginStar: stackoverflow也有人問類似的問題，也有人提出解決 12/03 14:37
→ OriginStar: 方法，所以技術上不是問題，CTO則是考量公司營運未來 12/03 14:38
→ OriginStar: 所以所預先的規劃，即使原PO不做也會找別人做，當然 12/03 14:40
→ OriginStar: 原PO不在意升遷、加薪、年終的話說自己不想負責這塊 12/03 14:41
→ OriginStar: 看能不能請其他同事負責也行 12/03 14:41
推 s06yji3: 又不是什麼違背良心的事情XD 12/03 14:52
推 hobnob: CTO不都是自家公司隨便喊的嗎。原PO就照做就好，不必爭論 12/03 17:18
→ hobnob: ，未來自己當CTO之後就可以做借鏡了 12/03 17:18
推 marc47: 如果只有幾十萬筆資料，愛怎麼變就讓他變，如果是幾千萬筆 12/04 00:45
→ marc47: 以上，要三思，pg的sql analyze很笨，更何況還要用array去 12/04 00:45
→ marc47: 拆，及做關聯，explain你看看cost可能都是full table scan 12/04 00:45
→ marc47: ，cost可能就嚇死人 12/04 00:45
→ ssccg: 那方法怎麼會寫code最快最懶，原po都說了用jpa hibernate 12/04 03:53
→ ssccg: 關係表直接@ManyToMany就完了，array一定要用postgres的 12/04 03:54
→ ssccg: native sql去寫，哪裡省了 12/04 03:54
→ ssccg: 好像有不少人包括一樓說技術債都以為是在說CTO提了個方便快 12/04 03:59
→ ssccg: 速的方法，不是吧這篇明明是在抱怨CTO提了個程式就比較難寫 12/04 03:59
→ ssccg: 又不合常規、但也說不出哪裡好(只說就有很大的彈性、關係表 12/04 04:00
→ ssccg: 多餘)，然後也沒什麼目的只為了少開個多餘(?)table 12/04 04:01
→ ssccg: 當然實際上也許CTO是有什麼考量，但顯然原PO沒接收到 12/04 04:03
噓 pttano: 可憐喔，爛CTO搭配junior ，真是一絕 12/04 09:44
推 ppc: 一樓精闢 12/04 13:47
→ superpandal: 一樓三樓是在自爆自己的為人嗎? XD 不過一堆沒講的都 12/05 18:50
→ superpandal: 是這樣 環境真的不好 12/05 18:50
→ superpandal: 言歸正傳 解法樓上都有人說了 用json postgres可提取 12/05 18:56
→ superpandal: json內的值 或者你取出來反序列化也可以 如果了解 12/05 18:58
→ superpandal: json本質 會覺得這格式很不錯 12/05 18:59
→ superpandal: postgres有一些json_為前綴的函數 12/05 19:02
推 come: 資料量不大或者存取不頻繁就會以可維護性來考量。 12/05 22:22
→ come: 或者說追求一致。但是一旦資料量大，就要考慮join成本。 12/05 22:23
→ come: 這個時候就會認真考慮用json了 12/05 22:24
→ come: jsonb是解multi-value的好工具 12/05 22:24
推 answermangtr: CTO CIO多的是 不是技術出身的咖 看多了啦 12/06 00:38
推 Killercat: 問他為啥要過度設計 有沒有有潛在的需求 12/08 08:00
→ Killercat: 會不會溝通這些東西往往就是junior senior的差別 12/08 08:01
推 BigCockman: 還好吧 反正規化的一種而已 做正規化不等於比較好維 12/08 10:53
→ BigCockman: 護跟擴展 坦白說硬要正規化是有點過時的想法了 12/08 10:53
→ superpandal: 這不是過度設計 是實作方式不同 一致性與靈活性是可 12/08 19:41
→ superpandal: 以兼得的 但市面上多半都是看到一致性強但改個小功能 12/08 19:42
→ superpandal: 就很累的東西 12/08 19:43
→ superpandal: 框架會加強一致性但也會縮限應用 巨無霸框架是災難 12/08 19:46