[請益] 關於關聯式資料庫處理重複架構的方式

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

Links booklink

Contact Us: admin [ a t ] ucptt.com