iT邦幫忙

0

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

  • 分享至 

  • xImage

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、...)
這樣做恰當嗎?有沒有甚麼缺點?

看更多先前的討論...收起先前的討論...
覺得亂可以拆
如果是擔心效能,不建議

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

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

最後就如樓下大大所說,想做就放手大膽做吧
╰( ̄▽ ̄)╭
感謝!我受益良多。
77012904 iT邦新手 3 級 ‧ 2019-12-31 11:06:28 檢舉
正規化做好,隨便你拆,現在的電腦要產生效能問題量要很大,會上來問這些問題的,實際應用面的量應該不大。

再說一次,資料庫正規化要做好,不然拆越多你就越早超生
正規化時也還真有些迷茫:
EX:會員交易紀錄 原有屬性(id、會員id、買入與賣出、摘要、金額....)---其中"買入與賣出"進行正規化的方式,作法該如何選擇?

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

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

還請不吝賜教!
我的建議是你先把SQL那些基本的 join 、union... 那些都學到熟練!
日後如果資料庫的資料是要做成api輸出, 每個api連結還會再對資料再一次分拆。
例如:當輸入使用者帳密request時, 系統要response電子郵件信箱 、電話...
參考我去年分享的發文:https://ithelp.ithome.com.tw/articles/10198346
當中是展示把Json結構的資料丟給 spark SQL 讓RDB的使用者用最熟悉的SQL語法來處理資料!
現今的趨勢不外乎是
Output: 資料庫撈取資料 -> Json -> 丟到網頁展示
Input : 網頁輸入資料 -> Json -> 寫進資料庫
等你把基本的SQL crud搞熟了, 再進一步學學寫程式處理Json資料吧!
不用執著於恰不恰當跟對不對,錯了,再改就好了!這樣累積的經驗才會多!
感恩
建議是要拆,除非你的會員表永遠都是那幾千筆,不然一定要拆
還有你的資料查詢寫法也有關係有人不管多少欄位,永遠都是 SELECT * 這樣下
哪你欄位萬一有上千個,你的會員有幾十萬,那你跑完這各表要多少時間
如果會員有上千萬呢,要抓多少資料到記憶體呢
建議樓主先去看看正規化的原則,再思考上面的這些問題
然後在想你要不要拆表,還有你UI的設計,拆表會不會比較好
雖然現在都有AJAX或是JQ可以多段預載,但你使用者一多的時候,效能不注意就會拖垮伺服器的回應速度,這些都是設計DB要注意的要點
我參考各位先進說明之後心得如下:
選擇不拆表:
有好處、只管理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記得加索引,可提升效能。
感恩
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中
3
海綿寶寶
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」
再來擔心效能問題
否則都是空談

看更多先前的回應...收起先前的回應...

https://ithelp.ithome.com.tw/upload/images/20191231/201091076gZKrUT3uq.png
菜鳥的心聲: ㄚ PM 就一直催催催, 要我快點改一改, 上線了才有數據/images/emoticon/emoticon39.gif

過年前不能好嗎? 一月底不能好嗎? 第一季不能好嗎?
/images/emoticon/emoticon40.gif

阿展 , 進度怎樣了 ? 東西還沒做出來還敢上來發廢文 !
ps. 你的老闆在背後正在發火/images/emoticon/emoticon18.gif

需 老闆不再我後面 他很火我也不知道

1
Darwin Watterson
iT邦好手 1 級 ‧ 2019-12-30 18:41:31

資料正規化應該就是你要的!
/images/emoticon/emoticon12.gif
至於缺點就是日後轉換成 nosql 時,會被目前的經驗給束縛吧!
/images/emoticon/emoticon29.gif
ps. 建議google多找找,選這篇只是檢索到的第一篇/images/emoticon/emoticon25.gif

看更多先前的回應...收起先前的回應...

根據正規化要求 我所述2種方式應該都能滿足1NF、2NF、3NF
我是想:若不常用的資訊不分開儲存,以後查詢數據都要全部撈出來然後再過濾使用,擔心跑這些撈資料流程會浪費效能,但所學不夠全面純熟,所以擔心是否有未知的風險。

就如大大您所言:日後轉換成 nosql 時,會被目前的經驗給束縛

關於這一點能否再提供一需參考資訊,謝謝!

年輕人不要急!先把RDB學到精通吧!

小魚 iT邦大師 1 級 ‧ 2019-12-30 20:11:47 檢舉

資料不用全撈阿,
選你要的欄位就好了

對!不用全撈,是我想偏了。謝謝提醒!
重點是大大您贊成將表拆開嗎?

4
一級屠豬士
iT邦大師 1 級 ‧ 2019-12-30 19:14:07

這樣做是不錯的方法.
不要有無謂的擔心,放手去大膽做.
至於經驗是逐步累積的,可以做對照比較.
另外除了MySQL以外,也可以試試看PostgreSQL.

謝謝!

ckp6250 iT邦好手 1 級 ‧ 2019-12-31 05:10:27 檢舉

  如果剛在規畫階段,還沒上線的話,
  採用 PostgreSQL 不吃虧。

  此外,若真的是【不常用屬性】,我可能考慮採用 json 欄位,所有不常用屬性通通擠成一欄,將來擴充新屬性也方便,不必再新增欄位。

1
gn00044255
iT邦新手 5 級 ‧ 2019-12-31 08:39:09

有些是需要拆開,像電話、Emial(可能會有1個以上)

感謝大家熱情釋疑 感覺無比溫暖!
大大 海綿寶寶 所言正中靶心,我因為剛初學不久所學尚淺,經常會感到徬徨,原本的擔心"亂與效能"原來只是瞎擔心一場,現在我已經能自信回到不需分常用不成用而拆表,需要拆的反而是如樓上大大gn00044255所說email phone...等等才需要拆。

愛的code,「既然你都誠心誠意的發問了,邦友當然會大發慈悲的給你答案。為了防止世界被破壞,為了守護世界的和平⋯」/images/emoticon/emoticon12.gif

ckp6250 iT邦好手 1 級 ‧ 2019-12-31 15:50:48 檢舉

還有防止地球暖化,保護生態平衡....

我要發表回答

立即登入回答