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

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