PTT評價

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

看板Soft_Job標題[請益] 關於關聯式資料庫處理重複架構的方式作者
f0921048125
(Nagao)
時間推噓14 推:14 噓:0 →:37

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

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

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

Budget
id/type/referId/income/expenses

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

--

※ PTT 留言評論
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 220.134.113.80 (臺灣)

※ 文章網址:
https://www.ptt.cc/Soft_Job/M.1671603742.A.79A

qss0512/21 14:33要關連可以兩個自己不同type去關連啊?然後再建一個city跟

qss0512/21 14:33country的關聯,三個表就可以互串,照理,你原本也會建一

qss0512/21 14:33個city-country的才對?不然你怎麼關聯的,除非你兩個ID都

qss0512/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

s06yji312/21 15:07你把budget的key分別放到county和city呀

s06yji312/21 15:11不一定要設定foreign key

t6414112/21 16:18兩張額外的 mapping 表ㄧ端分別對應 county 和 city,另

t6414112/21 16:18一端對應 budget 表。但會變成多對多且關聯起來不方便,

t6414112/21 16:18要在 mapping 表加 constraint 來避免多對多,不然就是如

t6414112/21 16:18樓上放棄外鍵

WaterLengend12/21 17:06那看起來就是把foreign key跟分散好幾張表的column

WaterLengend12/21 17:06統一在一張table就好了,就是樓上大大的做法

WaterLengend12/21 17:07還是說參考foreign key的table可能會出現例外?

我們有用On Delete的慣例 因此很少會選擇放棄實體關聯

※ 編輯: f0921048125 (111.83.165.50 臺灣), 12/21/2022 18:20:19

s06yji312/21 18:35既然這樣,我會把city和county不同的地方抽出分別建立兩

s06yji312/21 18:35個表。共同的地方一個表再去關聯預算。

BlueBird556612/21 18:44用jpa來說 你要的是DiscriminatorColumn跟

BlueBird556612/21 18:44DiscriminatorValue

BlueBird556612/21 18:45你的欄位會是 ID/TYPE/ID/INCOME/EXPENSES

internetms5212/21 19:07既然要獨立budget表,應該要各自擁有與county及cit

internetms5212/21 19:07y的關連表,麻煩的點是不想幫不同外鍵的表建立關連

internetms5212/21 19:07表嗎?,這取決於這些外鍵與budget的關系是否一致,

internetms5212/21 19:07若一致,你是可以直接把全部的外鍵放在同一張表,

internetms5212/21 19:07只用單張關聯表描述他

SHANGOYANYI12/21 19:41呃 弄張表有region_type跟region_id不就好了?

qss0512/21 20:17建一個對應表,看你想怎麼關連budget的ID,budget只存ID/I

qss0512/21 20:17NCOME/EXPENSES,也是可以?

alan310012/21 22:10這年頭還有人硬刪除呀也太可怕了

pvq21212/21 23:25多重多對多

ck23712/22 02:07我是覺得多對多挺適合處理這個場景,把城市直接當一個菜單

ck23712/22 02:07處理

TAKADO12/22 09:14用type+id,讓persistence層自己去關聯就好,資料維護時的

TAKADO12/22 09:14完整性用別的方式處理,DB設計有時候要取捨,太追求理想化

TAKADO12/22 09:14的schema有時候反而會造成更多問題。

neo527712/22 12:01可能硬刪除之後搬去hist吧

acgotaku12/22 12:23我偏好CityBudget,CountyBudget分兩張存

acgotaku12/22 12:24除非你budget要常常混再一起算,不然你還要搞 M-to-M 表

acgotaku12/22 12:26現在大型系統,不偏好這種作法 不利於擴展或是重構

acgotaku12/22 12:45譬如到時候需求變更county has many cities的時候

acgotaku12/22 12:48只需要算county budget總和,city budget只是county展開

acgotaku12/22 12:50你原先做的多對多mapping table就會很難重構

s86013412/22 14:30典型的正規化/反正規化選擇?

yyc121712/22 17:08我會分兩張表 沒必要為了省空間搞這麼麻煩

DrTech12/22 17:15分兩張表+1。書本上的各種 NF都太理想化。實際上不實用。

qss0512/22 23:14正規化有好有壞啦,好處是串連的時候很靈活,可以只挑你要

qss0512/22 23:14的資料,但有時候一個參數就要串3、4個表,但都不正規化也

qss0512/22 23:14很煩,明明一樣的參數,每個表都要存,如果又沒有統一的命

qss0512/22 23:14名規則,明明看起來一樣,但命名不一樣,就不知道有沒有延

qss0512/22 23:14伸意思,我之前待的兩個公司就是這兩個的極端…

Hitmear12/22 23:25怎麼沒人提到寬表?都塞一起就好

ChungLi556612/23 08:31看資料筆數 如果千萬筆以下的話隨便啦

timTan12/23 23:53這應該是分表比較好。