作者littlethe (東周流浪漢)
看板Soft_Job
標題Re: [請益] db要分table還是用一個field分類
時間Tue Aug 28 22:15:30 2018
這其實在大學就會學到的觀念了,
雖然我感覺大學的資料庫很多人教得不太好,
教得太抽象很容易讓人聽不懂...
anyway,
以我判斷,
這狀況要拆成3張表,
甲表是共用field,
乙表是A情境用,
丙表是B情境用,
然後甲表和乙表做成view專門給A情境用,
甲表再和丙表做成view給B情境用,
舉例子來講會比較好懂,
我們要設計遊戲,
遊戲裡有文官和將軍,
將軍沒有行政屬性,不能做行政職,
但有戰鬥屬性,可以帶兵,
文官有行政屬性沒戰鬥屬性,可以做行政,但不能帶兵,
所以我會先建一張表叫人物表,
表上有姓名,性別,生日等所有人物都有的屬性
(當然這時候會有天兵用年齡當field而不是生日,這就要打屁股了)
另一張表叫將軍表,
屬性有人物id,可以join到人物表,
還有戰鬥能力,戰鬥經驗值,
再一張表叫文官表,
屬性有人物id,外交能力,內政能力,研究能力...
再把將軍表和人物表變將軍view,
文官表和人物表變文官view,
要為軍隊選擇將軍時,就讀將軍view,
要選內閣時,就讀文官view,
要看人物列表時,就只讀人物表,
當然會有人既是將軍也是文官,例如凱末爾或艾森豪,
但在這種結構下,這種全才會同時存在將軍與文官的view中,
所以不用擔心
設計資料庫的道理和OO有共同之處,
就是一個表,和一個field最好只有一個很明確的存在目的,
而且要儘量讓結構可以很靈活的組合,
就像變形金鋼一樣可以變來變去,
如果一個表用來做一大堆事的話,
那就會變得很難維護了...一動就會扯到很多事,
細節前面與推文也很多人有講了就不多說,
要注意的地方大概就是要看一張表的數據量會不會超大,
如果超過百萬筆的話就要注意,
因為百萬筆的表再join其他表的話,很可能有效能問題,
如果要讓效能提升,
只做成2張表也行,各自應付A情境和B情境而不join,
就是所謂的反正規化,
但這樣做的缺點是若要查A情境和B情境共同的東西時的話,
就得用union了,
如查人物列表,變成要文官表union將軍表,
用field去把一個表模擬成兩張表...
我目前是想不到這樣做有什麼好處啦,
比較像是有人沒受過資料庫訓練,
自己幻想出的solution,
等A情境需要加些field或key,
B情境也需要加些field或key,
再來個C情境要加些field,
你就會看到傳說中的資料庫大魔王表,一張有上百個field的表,
你就可以唱首歌,
"我們的table,一眼望不完~,數不完的fields,峰峰相連到天邊~",
實務上我也碰過幾次這種前人留下的資料表坑,
費了九牛二虎之力還不一定解決得完,
因為表用在正式系統後,就不能隨便動了,動了容易出事,
所以會這樣告訴你,
也發現雖然資料庫大家都在用,
但很多人不太會設計,
有時候還真想去當老師教資料庫
※ 引述《asleepme (500年沒換暱稱了)》之銘言：
: 請教dba神人，之前遇到一個應用情境是這樣
: 我們有一組核心資料，跟2種服務
: 這2個服務(A、B)會用核心資料，去呈現不同的應用
: 所以A、B會有部分相同功能、部分不同功能
: 例如A會有功能 G、X、Y
: B會有功能 H、X、Y
: X、Y是一樣的功能只是A情境下用，或是B情境下用
: 所以X、Y功能在db中需要的structure也是一樣
: A、B儲存在X、Y裡面的資料是互相獨立的，沒有任何關聯
: 也就是說，在情境A下存進A.X的資料B完全不知道也沒差
: 在這情況下，我們可以為A的X功能建立一個 A_func_X 的table
: 同樣，B的X功能也可以建立一個 B_func_X 的table
: 但是這2個table的structure會一模一樣
: 也可以A、B共用一個table func_X
: 裡面有一個field叫type存A、或B，代表是哪個服務所建立的資料
: 想請教一下2種作法都適合嗎？
: 會有什麼後續要注意的狀況？
--
18歲前,我沉迷於動漫,後來把動漫丟了,好好面對真實世界,
30歲後,我再度沉迷於動漫,只是是帶著疲倦的心情,試著從中獲取一絲快樂
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 118.212.136.26
※ 文章網址: https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1535465769.A.1EB.html
※ 編輯: littlethe (115.238.194.35), 08/28/2018 22:41:14
1F：推 qa17b: 簽名檔有點悲傷 08/28 22:43
2F：推 bheegrl: 一絲快樂嗎?推抗"遊戲3人娘"，但是別在吃東西的時候看 08/28 22:51
3F：→ bheegrl: *坑 08/28 22:51
4F：推 t64141: 1沒設計好的資料表要重構真的難 08/28 23:02
5F：→ johnny94: 最尷尬的是你正確設計還會被沒學過的亂批評 08/28 23:51
6F：推 agogoman: 我看過中文講資料庫設計最深入淺出的是獨孤木的那一個系 08/29 00:10
7F：→ agogoman: 列, 我都建議先看過那一系列然後再回頭啃教科書, 相對會 08/29 00:11
8F：→ agogoman: 比較有感覺. 08/29 00:11
9F：推 TAKADO: 而且你去問亂設計的還會放大絕說 沒差啦 這個有差嗎？隨便 08/29 01:03
10F：→ TAKADO: 啦 08/29 01:03
11F：推 jj092357q4e3: 情境想的頗有趣，給推 08/29 01:05
12F：→ littlethe: 因為怕被人取代呀,所以很多人寧可一直做錯也不願認錯 08/29 01:15
13F：→ littlethe: 這也就是為什麼我不喜歡再去小公司了,因為小公司沒錢 08/29 01:16
14F：→ littlethe: 請能力好的人,就請一堆基礎很差自己摸出來的,就很容易 08/29 01:18
15F：→ littlethe: 將錯就錯,去攻擊對的人,變成劣幣趨逐良幣,久了公司就變 08/29 01:20
16F：→ littlethe: 得很恐怖...看公司正不正常,真的看薪水就可以推測出來 08/29 01:21
17F：推 xdraculax: 推 08/29 02:17
18F：推 pzyc79: 我也是這麼想的 但是沒辦法像這樣解釋的這麼清楚 08/29 03:18
19F：→ littlethe: 看來常打電動的好處就是可以舉出大家好理解的例子 08/29 03:31
※ 編輯: littlethe (115.238.194.35), 08/29/2018 03:55:32
20F：推 welcome0: 有時候會被ㄎㄅ說over design，但到了一定量就很難動啊. 08/29 09:47
21F：→ welcome0: .. 08/29 09:47
22F：推 iamyiz: 推。簽名檔qq 08/29 09:48
23F：推 johnny94: 有時候基本常識被說成是 over design 的情況也是很常見 08/29 10:23
24F：→ johnny94: 的 08/29 10:23
25F：推 a926: 老師教教窩 08/29 11:01
26F：推 ericsung: 一堆只會亂做又不承認自己錯 也不願改 懶得改 08/29 13:18
27F：→ littlethe: over design確實也會存在,但這很主觀,不管是不是over 08/29 15:08
28F：→ littlethe: design,至少設計者要有設計資料庫的觀念,有觀念,要補 08/29 15:09
29F：→ littlethe: 要修,要趕時間的話,也才知道要怎麼應對各種狀況 08/29 15:11
30F：→ littlethe: 而不是呆呆的自己胡思亂想亂猜怎麼做 08/29 15:12
31F：→ realbout: 怪了 這不就是正規化的目的... 08/29 20:57
32F：推 THEWORLDS: dba太缺就是這樣 遇到會弄得直接轉出資料重弄一個才爽 08/29 22:54
33F：→ THEWORLDS: 亂搞成本有時候會多出好幾E 不如花多點錢請一個好的DBA 08/29 22:55
34F：→ THEWORLDS: 不過台灣小公司大多是這樣 15萬打死 08/29 22:55
35F：→ littlethe: 但我發現很多公司沒有請DBA的念頭,也不知道正規化 08/30 01:54
36F：→ hakama99: 這情況我應該會拉兩個表單 一個將領table 08/31 16:46
37F：→ hakama99: 一個將領能力表單 欄位有將軍ID,type(軍師,軍人),能力 08/31 16:47
38F：→ hakama99: 文武官 08/31 16:49
39F：→ hakama99: 不然你的做法以後多一個宦官或其他類型的 就要多開表單 08/31 16:50
40F：→ hakama99: 仔細看了一下妳說的才是對的 不同類型欄位會不同 SORRY~ 08/31 16:53
41F：推 zased: 這篇寫得很好，感謝分享 09/01 03:57
42F：推 asleepme: +1 收益良多，值得收藏 XD 09/03 17:01