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