作者asleepme (500年沒換暱稱了)
看板Soft_Job
標題[請益] db要分table還是用一個field分類
時間Sun Aug 26 13:41:21 2018
請教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種作法都適合嗎？
會有什麼後續要注意的狀況？
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 223.136.180.153
※ 文章網址: https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1535262084.A.04D.html
1F：推 alihue: 你想一下，哪天A要客製B沒有的功能。 然後B再客製會發生什 08/26 13:46
2F：→ alihue: 麼事情，該怎麼設計就很清楚了 08/26 13:46
3F：推 RunRun5566: 把那個field換一個make more sense 的名字，哪天服務 08/26 15:06
4F：→ RunRun5566: 就算名稱換了也不會亂 08/26 15:06
5F：→ alog: 看未來是否需要擴展新功能、資料量去決定怎麼做 08/26 15:09
6F：推 alog: 額外增加一個欄位其實也行但記得打好index 08/26 15:14
以目前的情況，比較可能發生的是多一個C，然後有X、Y功能
如果有一天多一個 Z 功能，也應該會同時apply到A、B、C上
是說計畫很可能不照計畫發生就是...
這樣看起來A、B有各自的table好像比較適合我的狀況，不知道有沒有誤會？
剛剛在stackoverflow上看到一篇，如果你覺得是entity那建table
如果是attribute，那建field
follow這個原則，看起來也是建table？
※ 編輯: asleepme (223.136.180.153), 08/26/2018 15:19:23
7F：→ alog: 不過要留意應用程式那邊是否會有多餘的開銷，如果情境是大量 08/26 15:21
8F：→ alog: /高度頻繁使用時，A跟B日後有額外for A or B時的擴增容易在O 08/26 15:21
9F：→ alog: RM初始化/SQL拉資料時有多餘運算或傳輸開銷(資料欄位多或值 08/26 15:21
10F：→ alog: 的資料量大時會明顯)得需要針對A跟B做個別的欄位select 08/26 15:21
11F：→ alog: (上述講的是如果你之後共用一張表後來又加了only a or b欄 08/26 15:22
12F：→ alog: 位的情況) 08/26 15:22
13F：→ alog: 白話一點就是，之後你可能有C D E F 日後你多加了 Only C 08/26 15:30
14F：→ alog: 的欄位，其他 5 張表的相關程式再不做優化下通常都會初始 08/26 15:30
15F：→ alog: 化C跟拉C的欄位資料 08/26 15:30
16F：→ alog: 尤其是你程式是別人在寫時，大部分做的操作都是select * 這 08/26 15:31
17F：→ alog: 種一次拉全部 這種開銷就是很明顯 08/26 15:31
18F：→ alog: 資料量少其實沒感覺 但是今天如果要拼同時在線、高併發情境 08/26 15:33
19F：→ alog: 或有必要優化時就要留意 08/26 15:33
20F：→ alog: 除非你上頭的技術長還是主管有怪僻堅持不多開一張表 不然真 08/26 15:35
21F：→ alog: 的沒有必要做太多糾結 08/26 15:35
22F：→ alog: 當然這個建議還是要視你的平台為主 畢竟跟網友比起來，你會 08/26 15:36
23F：→ alog: 比較清楚自己在弄的東西 08/26 15:36
24F：推 ripple0129: 資料不相關的情況下，我個人會選擇拆表，省得麻煩， 08/26 17:10
25F：→ ripple0129: 到時候有新人不懂domain where沒下好資料就拉錯，且 08/26 17:10
26F：→ ripple0129: 測試上面每次都要驗證清楚有沒有拉到別邊的資料 08/26 17:10
27F：推 hua1040: 拆+1 08/26 18:28
28F：推 jhnny: 分開來...假設以後可能遇到A需要的欄位B沒有.或反之 08/26 19:42
29F：推 jej: 如果資料量每天都是百萬起跳 分析一下主要執行的系統吧 08/26 21:02
30F：→ jej: 次要的系統用trigger分出去 免得有人用了爛sql整個系統死掉 08/26 21:04
31F：→ jej: 阿如果一個月都不到一萬 反正規可以給你快速度 08/26 21:05
32F：→ jej: 阿如果table垮了不同執行單位 還是拆了吧 免得糾紛 08/26 21:06
33F：推 backforward: 沒有共用性幹嘛放一起，又不是寫程式 08/26 21:55
34F：→ asleepme: 感謝高手們經驗分享～ 08/26 23:13