作者:
asleepme (500年沒換暱稱了)
2018-08-26 13:41:21請教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種作法都適合嗎？
會有什麼後續要注意的狀況？
作者:
alihue (wanda wanda)
2018-08-26 13:46:00你想一下，哪天A要客製B沒有的功能。 然後B再客製會發生什麼事情，該怎麼設計就很清楚了
把那個field換一個make more sense 的名字，哪天服務就算名稱換了也不會亂
作者:
alog (A肉哥)
2018-08-26 15:09:00看未來是否需要擴展新功能、資料量去決定怎麼做額外增加一個欄位其實也行但記得打好index不過要留意應用程式那邊是否會有多餘的開銷，如果情境是大量/高度頻繁使用時，A跟B日後有額外for A or B時的擴增容易在ORM初始化/SQL拉資料時有多餘運算或傳輸開銷(資料欄位多或值的資料量大時會明顯)得需要針對A跟B做個別的欄位select(上述講的是如果你之後共用一張表後來又加了only a or b欄位的情況)白話一點就是，之後你可能有C D E F 日後你多加了 Only C的欄位，其他 5 張表的相關程式再不做優化下通常都會初始化C跟拉C的欄位資料尤其是你程式是別人在寫時，大部分做的操作都是select * 這種一次拉全部 這種開銷就是很明顯資料量少其實沒感覺 但是今天如果要拼同時在線、高併發情境或有必要優化時就要留意除非你上頭的技術長還是主管有怪僻堅持不多開一張表 不然真的沒有必要做太多糾結當然這個建議還是要視你的平台為主 畢竟跟網友比起來，你會比較清楚自己在弄的東西
資料不相關的情況下，我個人會選擇拆表，省得麻煩，到時候有新人不懂domain where沒下好資料就拉錯，且測試上面每次都要驗證清楚有沒有拉到別邊的資料
作者:
hua1040 (大米)
2018-08-26 18:28:00拆+1
作者:
jhnny (jhnny)
2018-08-26 19:42:00分開來...假設以後可能遇到A需要的欄位B沒有.或反之
作者:
jej (晃奶大馬桶)
2018-08-26 21:02:00如果資料量每天都是百萬起跳 分析一下主要執行的系統吧次要的系統用trigger分出去 免得有人用了爛sql整個系統死掉阿如果一個月都不到一萬 反正規可以給你快速度阿如果table垮了不同執行單位 還是拆了吧 免得糾紛
作者:
asleepme (500年沒換暱稱了)
2018-08-26 23:13:00感謝高手們經驗分享～