→ qss05: 要關連可以兩個自己不同type去關連啊？然後再建一個city跟12/21 14:33
→ qss05: country的關聯，三個表就可以互串，照理，你原本也會建一12/21 14:33
→ qss05: 個city-country的才對？不然你怎麼關聯的，除非你兩個ID都12/21 14:33
→ qss05: 一樣？12/21 14:33
我上面只是舉個例子 實際上有些情況是city和country並沒有關聯性 所以也沒有關聯表
可以直接參照
目前的做法就是在city和country底下各自建立一張budget表
但這種方式在遇到budget表底下也有很多與其關聯的表
維護上就會十分麻煩...
以MSSQL來講 應該是做不到type/referId，可以和不同的表做關聯吧?
※ 編輯: f0921048125 (220.134.113.80 臺灣), 12/21/2022 14:49:26
※ 編輯: f0921048125 (220.134.113.80 臺灣), 12/21/2022 14:51:13
推 s06yji3: 你把budget的key分別放到county和city呀12/21 15:07
推 s06yji3: 不一定要設定foreign key12/21 15:11
→ t64141: 兩張額外的 mapping 表ㄧ端分別對應 county 和 city，另12/21 16:18
→ t64141: 一端對應 budget 表。但會變成多對多且關聯起來不方便，12/21 16:18
→ t64141: 要在 mapping 表加 constraint 來避免多對多，不然就是如12/21 16:18
→ t64141: 樓上放棄外鍵12/21 16:18
推 WaterLengend: 那看起來就是把foreign key跟分散好幾張表的column12/21 17:06
→ WaterLengend: 統一在一張table就好了，就是樓上大大的做法12/21 17:06
→ WaterLengend: 還是說參考foreign key的table可能會出現例外？12/21 17:07
我們有用On Delete的慣例
因此很少會選擇放棄實體關聯
※ 編輯: f0921048125 (111.83.165.50 臺灣), 12/21/2022 18:20:19
推 s06yji3: 既然這樣，我會把city和county不同的地方抽出分別建立兩 12/21 18:35
→ s06yji3: 個表。共同的地方一個表再去關聯預算。 12/21 18:35
→ BlueBird5566: 用jpa來說 你要的是DiscriminatorColumn跟 12/21 18:44
→ BlueBird5566: DiscriminatorValue 12/21 18:44
→ BlueBird5566: 你的欄位會是 ID/TYPE/ID/INCOME/EXPENSES 12/21 18:45
推 internetms52: 既然要獨立budget表，應該要各自擁有與county及cit 12/21 19:07
→ internetms52: y的關連表，麻煩的點是不想幫不同外鍵的表建立關連 12/21 19:07
→ internetms52: 表嗎?，這取決於這些外鍵與budget的關系是否一致， 12/21 19:07
→ internetms52: 若一致，你是可以直接把全部的外鍵放在同一張表， 12/21 19:07
→ internetms52: 只用單張關聯表描述他 12/21 19:07
推 SHANGOYANYI: 呃 弄張表有region_type跟region_id不就好了？ 12/21 19:41
推 qss05: 建一個對應表，看你想怎麼關連budget的ID，budget只存ID/I 12/21 20:17
→ qss05: NCOME/EXPENSES，也是可以？ 12/21 20:17
→ alan3100: 這年頭還有人硬刪除呀也太可怕了 12/21 22:10
推 pvq212: 多重多對多 12/21 23:25
推 ck237: 我是覺得多對多挺適合處理這個場景，把城市直接當一個菜單 12/22 02:07
→ ck237: 處理 12/22 02:07
推 TAKADO: 用type+id，讓persistence層自己去關聯就好，資料維護時的 12/22 09:14
→ TAKADO: 完整性用別的方式處理，DB設計有時候要取捨，太追求理想化 12/22 09:14
→ TAKADO: 的schema有時候反而會造成更多問題。 12/22 09:14
推 neo5277: 可能硬刪除之後搬去hist吧 12/22 12:01
→ acgotaku: 我偏好CityBudget,CountyBudget分兩張存 12/22 12:23
→ acgotaku: 除非你budget要常常混再一起算,不然你還要搞 M-to-M 表 12/22 12:24
→ acgotaku: 現在大型系統,不偏好這種作法 不利於擴展或是重構 12/22 12:26
→ acgotaku: 譬如到時候需求變更county has many cities的時候 12/22 12:45
→ acgotaku: 只需要算county budget總和,city budget只是county展開 12/22 12:48
→ acgotaku: 你原先做的多對多mapping table就會很難重構 12/22 12:50
推 s860134: 典型的正規化/反正規化選擇？ 12/22 14:30
推 yyc1217: 我會分兩張表 沒必要為了省空間搞這麼麻煩 12/22 17:08
→ DrTech: 分兩張表+1。書本上的各種 NF都太理想化。實際上不實用。 12/22 17:15
→ qss05: 正規化有好有壞啦，好處是串連的時候很靈活，可以只挑你要 12/22 23:14
→ qss05: 的資料，但有時候一個參數就要串3、4個表，但都不正規化也 12/22 23:14
→ qss05: 很煩，明明一樣的參數，每個表都要存，如果又沒有統一的命 12/22 23:14
→ qss05: 名規則，明明看起來一樣，但命名不一樣，就不知道有沒有延 12/22 23:14
→ qss05: 伸意思，我之前待的兩個公司就是這兩個的極端… 12/22 23:14
推 Hitmear: 怎麼沒人提到寬表？都塞一起就好 12/22 23:25
→ ChungLi5566: 看資料筆數 如果千萬筆以下的話隨便啦 12/23 08:31
→ timTan: 這應該是分表比較好。 12/23 23:53
→ brucetu: 追求完美正規化只代表你的資料量根本不大 12/24 22:29
→ brucetu: 撈個資料要跨好幾張表 12/24 22:30
推 cathychg: 重複架構是什麼。 @@ 12/25 01:41
→ cathychg: DD ERdiagram 正規化 就三個重點 12/25 01:43
→ cathychg: 資料關連圖 切正規化 。。一對多 多對一。 12/25 01:44
推 cathychg: 多對多 很口能出現 bug 大部分還是一對多 正規化 然後畫 12/25 01:45
→ cathychg: 關連圖 之後個表格需要視窗化。。。有的不用 12/25 01:45
→ cathychg: 這叫大學理論基礎 12/25 01:46
→ cathychg: 視窗化的功能 陽春的 慢慢逐步調整到完整的 跟專案時程 12/25 01:47
→ cathychg: 有關 12/25 01:47
→ cathychg: 譬如說 進銷存系統 客戶名單 產品代號 產品品項 客戶訂 12/25 01:48
→ cathychg: 單 庫存管理都是設計的內容 12/25 01:48
→ cathychg: 視窗系統的頁面要提供什麼資料 這專案經理與工程師要討 12/25 01:49
→ cathychg: 論的 12/25 01:49
→ cathychg: 訂便當系統 可以看看 功能很陽春 但是該有的都有了 12/25 01:50
推 cathychg: 那問題是。 server 是架設在那 穩定度呢？ 餐飲業是 12/25 01:51
→ cathychg: 門檻低的 高門檻的 呢… 12/25 01:51
推 cathychg: 你確定你們考過大學嗎？你確定學有專精嘛？你確定資深同 12/25 01:53
→ cathychg: 事可以理解每個人的特質派與不同的任務完成專業能力等 12/25 01:53
→ cathychg: 級高的專案嗎 12/25 01:53
→ cathychg: 每個人的特質與特長不同 所學的也不同 有的專長在法律系 12/25 01:54
→ cathychg: 那簡直一廂情願的要硬湊在一起啊 12/25 01:54
→ cathychg: 法律系 會計系 就去屎嘛 12/25 01:55
→ cathychg: 問題在於 一個國科會的案子 不是國家重點的研發團隊 那 12/25 01:56
→ cathychg: 怎麼類比 12/25 01:56
→ cathychg: 第一個公司 那叫包山包海 接下來就是純軟 或專門infra 12/25 01:58
→ cathychg: 那原本生技業的受到的牽連就越來越少 12/25 01:58
→ cathychg: 成大有醫學院啊… 12/25 01:58
→ cathychg: 成大電機有電工實習 如果真的有上過電工實習的化 12/25 01:59
→ cathychg: 包山包海的國家型計畫不可能的 12/25 01:59
推 cathychg: 資管系 應該是基礎中的基礎了 我沒作弊 靠自己上大學的 12/25 02:01
→ cathychg: 包山包海的國家級預算與計畫 才可以吃掉那樣多人力 現在 12/25 02:02
→ cathychg: 不可能 12/25 02:02
→ lchcoding: 樓上是不是回錯篇阿！ 12/25 08:39