PTT職涯區 / Soft_Job (軟體人)

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

看板Soft_Job (軟體人)作者 (500年沒換暱稱了)時間7年前 (2018/08/26 13:41), 7年前編輯推噓8(8推 0噓 26→)
留言34則, 9人參與, 7年前最新討論串1/3 (看更多)
請教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
推
08/26 13:46, 7年前 , 1F
你想一下，哪天A要客製B沒有的功能。 然後B再客製會發生什
08/26 13:46, 1F
→
08/26 13:46, 7年前 , 2F
麼事情，該怎麼設計就很清楚了
08/26 13:46, 2F
推
08/26 15:06, 7年前 , 3F
把那個field換一個make more sense 的名字，哪天服務
08/26 15:06, 3F
→
08/26 15:06, 7年前 , 4F
就算名稱換了也不會亂
08/26 15:06, 4F
→
08/26 15:09, 7年前 , 5F
看未來是否需要擴展新功能、資料量去決定怎麼做
08/26 15:09, 5F
推
08/26 15:14, 7年前 , 6F
額外增加一個欄位其實也行但記得打好index
08/26 15:14, 6F
以目前的情況，比較可能發生的是多一個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
→
08/26 15:21, 7年前 , 7F
不過要留意應用程式那邊是否會有多餘的開銷，如果情境是大量
08/26 15:21, 7F
→
08/26 15:21, 7年前 , 8F
/高度頻繁使用時，A跟B日後有額外for A or B時的擴增容易在O
08/26 15:21, 8F
→
08/26 15:21, 7年前 , 9F
RM初始化/SQL拉資料時有多餘運算或傳輸開銷(資料欄位多或值
08/26 15:21, 9F
→
08/26 15:21, 7年前 , 10F
的資料量大時會明顯)得需要針對A跟B做個別的欄位select
08/26 15:21, 10F
→
08/26 15:22, 7年前 , 11F
(上述講的是如果你之後共用一張表後來又加了only a or b欄
08/26 15:22, 11F
→
08/26 15:22, 7年前 , 12F
位的情況)
08/26 15:22, 12F
→
08/26 15:30, 7年前 , 13F
白話一點就是，之後你可能有C D E F 日後你多加了 Only C
08/26 15:30, 13F
→
08/26 15:30, 7年前 , 14F
的欄位，其他 5 張表的相關程式再不做優化下通常都會初始
08/26 15:30, 14F
→
08/26 15:30, 7年前 , 15F
化C跟拉C的欄位資料
08/26 15:30, 15F
→
08/26 15:31, 7年前 , 16F
尤其是你程式是別人在寫時，大部分做的操作都是select * 這
08/26 15:31, 16F
→
08/26 15:31, 7年前 , 17F
種一次拉全部 這種開銷就是很明顯
08/26 15:31, 17F
→
08/26 15:33, 7年前 , 18F
資料量少其實沒感覺 但是今天如果要拼同時在線、高併發情境
08/26 15:33, 18F
→
08/26 15:33, 7年前 , 19F
或有必要優化時就要留意
08/26 15:33, 19F
→
08/26 15:35, 7年前 , 20F
除非你上頭的技術長還是主管有怪僻堅持不多開一張表 不然真
08/26 15:35, 20F
→
08/26 15:35, 7年前 , 21F
的沒有必要做太多糾結
08/26 15:35, 21F
→
08/26 15:36, 7年前 , 22F
當然這個建議還是要視你的平台為主 畢竟跟網友比起來，你會
08/26 15:36, 22F
→
08/26 15:36, 7年前 , 23F
比較清楚自己在弄的東西
08/26 15:36, 23F
推
08/26 17:10, 7年前 , 24F
資料不相關的情況下，我個人會選擇拆表，省得麻煩，
08/26 17:10, 24F
→
08/26 17:10, 7年前 , 25F
到時候有新人不懂domain where沒下好資料就拉錯，且
08/26 17:10, 25F
→
08/26 17:10, 7年前 , 26F
測試上面每次都要驗證清楚有沒有拉到別邊的資料
08/26 17:10, 26F
推
08/26 18:28, 7年前 , 27F
拆+1
08/26 18:28, 27F
推
08/26 19:42, 7年前 , 28F
分開來...假設以後可能遇到A需要的欄位B沒有.或反之
08/26 19:42, 28F
推
08/26 21:02, 7年前 , 29F
如果資料量每天都是百萬起跳 分析一下主要執行的系統吧
08/26 21:02, 29F
→
08/26 21:04, 7年前 , 30F
次要的系統用trigger分出去 免得有人用了爛sql整個系統死掉
08/26 21:04, 30F
→
08/26 21:05, 7年前 , 31F
阿如果一個月都不到一萬 反正規可以給你快速度
08/26 21:05, 31F
→
08/26 21:06, 7年前 , 32F
阿如果table垮了不同執行單位 還是拆了吧 免得糾紛
08/26 21:06, 32F
推
08/26 21:55, 7年前 , 33F
沒有共用性幹嘛放一起，又不是寫程式
08/26 21:55, 33F
→
08/26 23:13, 7年前 , 34F
感謝高手們經驗分享～
08/26 23:13, 34F
‣ 更多 asleepme 的文章
文章代碼(AID): #1RWZs41D (Soft_Job)
Soft_Job 近期熱門文章
更多 近期熱門文章 >>
PTT職涯區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 asleepme 的文章
文章代碼(AID): #1RWZs41D (Soft_Job)