資料庫規劃時，EX：會員表中屬性非常多感覺亂也擔心效能，請教可以拆成2個不同表嗎?

php mysql 資料管理

愛的code 2019-12-30 17:56:50 ‧ 2847 瀏覽

分享至

EX：
members
(phone、password、email、name、...address、birthday、ID_num、company_name、...)
拆成
常用屬性表
members
(phone、password、email、name、...)

以及不常用屬性表
m_profiles
(address、birthday、ID_num、company_name、...)
這樣做恰當嗎？有沒有甚麼缺點？

看更多先前的討論...收起先前的討論...

小碼農米爾 iT邦高手 1 級 ‧ 2019-12-31 09:08:07 檢舉

覺得亂可以拆
如果是擔心效能，不建議

查詢效能主要是依靠索引
只要注意 where 有正確使用索引，select 只取需要的欄位
避免全表掃描，效能應該不會太差

反而拆表用到 join 的地方比較難優化

最後就如樓下大大所說，想做就放手大膽做吧
╰（￣▽￣）╭

愛的code iT邦新手 4 級 ‧ 2019-12-31 10:12:24 檢舉

感謝！我受益良多。

77012904 iT邦新手 3 級 ‧ 2019-12-31 11:06:28 檢舉

正規化做好，隨便你拆，現在的電腦要產生效能問題量要很大，會上來問這些問題的，實際應用面的量應該不大。

再說一次，資料庫正規化要做好，不然拆越多你就越早超生

愛的code iT邦新手 4 級 ‧ 2019-12-31 12:22:41 檢舉

正規化時也還真有些迷茫：
EX：會員交易紀錄原有屬性(id、會員id、買入與賣出、摘要、金額....)---其中"買入與賣出"進行正規化的方式，作法該如何選擇？

做法一之拆成如下2表：
1、交易類型 (id、類型)
2、會員交易紀錄 (id、會員id、交易類型_id、摘要、金額....)

做法二之拆成如下2表：
1、會員買入紀錄 (id、會員id、摘要、金額....)
2、會員賣出紀錄 (id、會員id、摘要、金額....)

還請不吝賜教！

Darwin Watterson iT邦好手 1 級 ‧ 2019-12-31 13:33:20 檢舉

我的建議是你先把SQL那些基本的 join 、union... 那些都學到熟練！
日後如果資料庫的資料是要做成api輸出, 每個api連結還會再對資料再一次分拆。
例如：當輸入使用者帳密request時, 系統要response電子郵件信箱、電話...

Darwin Watterson iT邦好手 1 級 ‧ 2019-12-31 13:36:29 檢舉

參考我去年分享的發文：https://ithelp.ithome.com.tw/articles/10198346
當中是展示把Json結構的資料丟給 spark SQL 讓RDB的使用者用最熟悉的SQL語法來處理資料！

Darwin Watterson iT邦好手 1 級 ‧ 2019-12-31 13:39:54 檢舉

現今的趨勢不外乎是
Output: 資料庫撈取資料 -> Json -> 丟到網頁展示
Input : 網頁輸入資料 -> Json -> 寫進資料庫
等你把基本的SQL crud搞熟了, 再進一步學學寫程式處理Json資料吧！

Darwin Watterson iT邦好手 1 級 ‧ 2019-12-31 13:42:51 檢舉

不用執著於恰不恰當跟對不對，錯了，再改就好了！這樣累積的經驗才會多！

愛的code iT邦新手 4 級 ‧ 2019-12-31 14:48:50 檢舉

感恩

窮嘶發發發 iT邦高手 1 級 ‧ 2020-01-02 10:14:15 檢舉

建議是要拆，除非你的會員表永遠都是那幾千筆，不然一定要拆
還有你的資料查詢寫法也有關係有人不管多少欄位，永遠都是 SELECT * 這樣下
哪你欄位萬一有上千個，你的會員有幾十萬，那你跑完這各表要多少時間
如果會員有上千萬呢，要抓多少資料到記憶體呢
建議樓主先去看看正規化的原則，再思考上面的這些問題
然後在想你要不要拆表，還有你UI的設計，拆表會不會比較好
雖然現在都有AJAX或是JQ可以多段預載，但你使用者一多的時候，效能不注意就會拖垮伺服器的回應速度，這些都是設計DB要注意的要點

愛的code iT邦新手 4 級 ‧ 2020-01-02 11:52:16 檢舉

我參考各位先進說明之後心得如下：
選擇不拆表：
有好處、只管理1張表，相對2張表=圖形化介面查看表只需察看一個表，程式碼撈資料也只需要select一個表....的確較為簡單。
需注意、select時必須精準使用where，而自認這應該是我身為程式碼工作者該有的職責。
總之，攸關UI、查詢效能、...等等問題影響的主要關鍵，還是在於程式碼的方式，而不是拆表。

WQ iT邦新手 2 級 ‧ 2020-01-06 10:49:07 檢舉

給"愛的CODE"一個不同的觀點。
1.拆不拆TABLE取決於功能或用途。例如:想記錄每一次會員登入的時間，此時..就得用另一個TABLE記錄。
2.參考正規化原則，效能其實問題不大。現在的設備那怕是一般PC都足夠你用了，除非你是商業化使用，同時上線人數達50人以上，且運算邏輯複雜。
3.SQL切勿使用 "*號" 查詢，再強大的資料庫也會吃記憶體。
4.大型TABLE記得加索引，可提升效能。

愛的code iT邦新手 4 級 ‧ 2020-01-06 11:32:16 檢舉

感恩

登入發表討論

直播研討會

{{ item.channelVendor }} {{ item.webinarstarted }} |

直播中

4 個回答

海綿寶寶

iT邦大神 1 級 ‧ 2019-12-31 10:00:12

最佳解答

系統分析、資料庫規劃其實都蠻主觀的
我的主觀是
「沒有必要拆成兩個 table」
「討論資訊系統，多用量化數據，少用感覺形容詞」

會員表中屬性非常多
所謂多是100個、500個還是1000個?
你知道 MySQL 一個 table 中最多可以幾個欄位嗎?

感覺亂
這是主觀感覺
你覺得10個table，每個 table 50 個欄位很「亂」
我覺得20個table，每個 table 25 個欄位比較「亂」
因為我不知道「常用」的量化定義是什麼
而未來如果當任何欄位由「常用變成不常用」「不常用變成常用」的話，要不要來修改兩個 table 的定義？對應的程式？

擔心效能
MySQL 已經被廣泛使用這麼多年
如果要擔心他的效能問題
again, 先收集量化數據
「資料筆數」「SQL 指令」「建立 Index」「Response Time」
再來擔心效能問題
否則都是空談