[請益] db要分table還是用一個field分類

[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種作法都適合嗎？
會有什麼後續要注意的狀況？

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 223.136.180.153
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1535262084.A.04D.html
推 alihue: 你想一下，哪天A要客製B沒有的功能。 然後B再客製會發生什
→ alihue: 麼事情，該怎麼設計就很清楚了
推 RunRun5566: 把那個field換一個make more sense 的名字，哪天服務
→ RunRun5566: 就算名稱換了也不會亂
→ alog: 看未來是否需要擴展新功能、資料量去決定怎麼做
推 alog: 額外增加一個欄位其實也行但記得打好index
以目前的情況，比較可能發生的是多一個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
→ alog: 不過要留意應用程式那邊是否會有多餘的開銷，如果情境是大量
→ alog: /高度頻繁使用時，A跟B日後有額外for A or B時的擴增容易在O
→ alog: RM初始化/SQL拉資料時有多餘運算或傳輸開銷(資料欄位多或值
→ alog: 的資料量大時會明顯)得需要針對A跟B做個別的欄位select
→ alog: (上述講的是如果你之後共用一張表後來又加了only a or b欄
→ alog: 位的情況)
→ alog: 白話一點就是，之後你可能有C D E F 日後你多加了 Only C
→ alog:  的欄位，其他 5 張表的相關程式再不做優化下通常都會初始
→ alog: 化C跟拉C的欄位資料
→ alog: 尤其是你程式是別人在寫時，大部分做的操作都是select * 這
→ alog: 種一次拉全部 這種開銷就是很明顯
→ alog: 資料量少其實沒感覺 但是今天如果要拼同時在線、高併發情境
→ alog: 或有必要優化時就要留意
→ alog: 除非你上頭的技術長還是主管有怪僻堅持不多開一張表 不然真
→ alog: 的沒有必要做太多糾結
→ alog: 當然這個建議還是要視你的平台為主 畢竟跟網友比起來，你會
→ alog: 比較清楚自己在弄的東西
推 ripple0129: 資料不相關的情況下，我個人會選擇拆表，省得麻煩，
→ ripple0129: 到時候有新人不懂domain where沒下好資料就拉錯，且
→ ripple0129: 測試上面每次都要驗證清楚有沒有拉到別邊的資料
推 hua1040: 拆+1
推 jhnny: 分開來...假設以後可能遇到A需要的欄位B沒有.或反之
推 jej: 如果資料量每天都是百萬起跳 分析一下主要執行的系統吧
→ jej: 次要的系統用trigger分出去 免得有人用了爛sql整個系統死掉
→ jej: 阿如果一個月都不到一萬 反正規可以給你快速度
→ jej: 阿如果table垮了不同執行單位 還是拆了吧 免得糾紛
推 backforward: 沒有共用性幹嘛放一起，又不是寫程式
→ asleepme: 感謝高手們經驗分享～