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

[f0921048125 (Nagao)]

最近在開發功能的時候
有遇到一個滿困擾的問題
在某些需求中，可能會遇到數張結構相同的表，
只是因為外來鍵參考的表不一樣而分化
比如說有個紀錄縣市總預算的需求
假設縣和市都有自己的東西要存，因此不能存在同一張表
必須是獨立的兩張表
那資料庫預算表可能會長這樣

CountyBudget
  id/countyId/income/expenses
CityBudget
  id/cityId/income/expenses

在程式面或許可以把預算表的屬性抽一個物件
在縣市底下放這個物件進去
但資料庫這邊除了重複定義欄位之外 有其他方式可以解決嗎?
有想過類似這樣的方式

Budget
  id/type/referId/income/expenses

但是問題是這樣就沒辦法建立實體關聯了QQ

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