[請益] 資料庫規劃問題 (MySQL)

看板PHP作者 (MineMine)時間13年前 (2012/03/13 23:48), 編輯推噓4(5151)
留言57則, 11人參與, 最新討論串1/5 (看更多)
問個PHP+MySQL的問題 資料庫有兩種規劃方式 A: 有100個欄位 但資料有10萬筆 B: 20個資料表,每個資料表5個欄位 資料有200萬筆 這兩種方式,讀取、寫入、搜尋 請幫忙比較這二種規劃方式 電腦負載及執行速度 本身是新手,如果有問錯的地方請多多包含 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 122.117.32.157

03/13 23:53, , 1F
挺有趣的問題....我也思考過,不過刷個百萬筆資料去比較過
03/13 23:53, 1F

03/14 01:35, , 2F
^沒
03/14 01:35, 2F

03/14 01:44, , 3F
我怎感覺 有點像是課本問題阿XDD 是我錯覺嗎
03/14 01:44, 3F

03/14 09:12, , 4F
課本應該只會教正規化吧 = ="
03/14 09:12, 4F

03/14 10:11, , 5F
這就是 OLAP 和 OLTP 的不同,要根據你的目的去設計資料庫
03/14 10:11, 5F

03/14 10:15, , 6F
OLAP:利於查詢。 OLTP:利於新增、修改、刪除。
03/14 10:15, 6F

03/14 10:17, , 7F
有時還會需要把 OLTP轉成OLAP,這時候就要反正規化。
03/14 10:17, 7F

03/14 12:31, , 8F
這確實像課本問題
03/14 12:31, 8F

03/14 13:07, , 9F
先聲明這並不是課本問題,是我實務上遇到的
03/14 13:07, 9F

03/14 13:07, , 10F
例如做一個龐大的會員資料庫,很有可能要記錄超過100個
03/14 13:07, 10F

03/14 13:08, , 11F
欄位以上,就會考慮這些問題,此外,就算是課本問題
03/14 13:08, 11F

03/14 13:08, , 12F
也是可以討論吧,怎麼好像一副怕幫別人做作業的感覺
03/14 13:08, 12F

03/14 14:09, , 13F
本來就不應該請別人做作業 當然也不想幫
03/14 14:09, 13F

03/14 14:45, , 14F
@_@ 我覺得這不是作業問題,感覺這是個好問題
03/14 14:45, 14F

03/14 15:52, , 15F
A只有一個資料表?
03/14 15:52, 15F

03/14 16:02, , 16F
我有請人幫我做作業嗎?我只是說就算是作業就不能討論?
03/14 16:02, 16F

03/14 16:03, , 17F
我只是單就資料庫的規劃請益,一起思考好做法
03/14 16:03, 17F

03/14 16:03, , 18F
我也不是要請誰幫忙,我現在是有像學校做PAPER那樣
03/14 16:03, 18F

03/14 16:04, , 19F
指定格式跟字數嗎?請動一動閣下寫程式的頭腦判斷好嗎?
03/14 16:04, 19F

03/14 16:05, , 20F
莫名其妙有建設性的回答看不到半個,只看到某酸民一副
03/14 16:05, 20F

03/14 16:06, , 21F
不可一世好像別人在求它似的,你若懂不想回答可以不要
03/14 16:06, 21F

03/14 16:06, , 22F
回應,不要回那種自私自利的話,沒人要你幫忙
03/14 16:06, 22F

03/14 16:07, , 23F
如果你也不懂,那你講那種話實在是傷你父母的心,沒家教
03/14 16:07, 23F

03/14 16:08, , 24F
YANLI2對,理論上是,單純想比較,多欄位到底要全塞在同
03/14 16:08, 24F

03/14 16:09, , 25F
資料表,還是要拆多資料表,比較筆數龐大時的處理效率
03/14 16:09, 25F

03/14 16:11, , 26F
有求於人 態度還是好一點吧
03/14 16:11, 26F

03/14 16:13, , 27F
會覺得像是作業 一部分也是因為你自己也沒提供什麼想法
03/14 16:13, 27F

03/14 19:19, , 28F
講態度有分先後,我發文的時候自認是請益或討論心態
03/14 19:19, 28F

03/14 19:20, , 29F
而且我也聲明了並不是作業,甚至連實務的思考點都說了
03/14 19:20, 29F

03/14 19:22, , 30F
何必一直強調他是否為作業? 這點我覺得很奇怪
03/14 19:22, 30F

03/14 19:22, , 31F
所以才說就算是作業,難道就不能討論不能請教嗎?
03/14 19:22, 31F

03/14 19:52, , 32F
你可以自己測試看看 以相同資料表結構、索引下去插
03/14 19:52, 32F

03/14 19:53, , 33F
個一千萬筆資料進同一資料表 再測試插入新增搜索所需要
03/14 19:53, 33F

03/14 19:53, , 34F
花費的時間能不能接受
03/14 19:53, 34F

03/14 19:54, , 35F
以我的經驗 大多時候是使用是越少資料表越好
03/14 19:54, 35F

03/14 19:54, , 36F
(在資料結構完全相同的情況下)
03/14 19:54, 36F

03/14 20:29, , 37F
嗯跟我想的一樣,只是覺得這樣規劃很醜,有程式潔癖
03/14 20:29, 37F

03/14 20:29, , 38F
常搜尋/讀取/修改 和很少修改的欄位分開
03/14 20:29, 38F

03/14 20:30, , 39F
那如果是我要從1000萬筆拉一筆資料出來where sn=$sn
03/14 20:30, 39F

03/14 20:32, , 40F
建好 index,拉出來後丟 memcache 之類的
03/14 20:32, 40F

03/14 20:32, , 41F
discuz 之類的討論區有按照尾數之類的分散在十個表
03/14 20:32, 41F

03/14 20:33, , 42F
但你搜尋就要搜10個表
03/14 20:33, 42F

03/14 20:33, , 43F
chrisQQ這方式很棒很聰明,不失為兩全其美的好方法
03/14 20:33, 43F

03/14 20:34, , 44F
但是欄位分開會不會造成資料庫管理的錯亂?
03/14 20:34, 44F

03/14 20:35, , 45F
如果你喜歡撈出來的時候拼在一起,就 join 起來
03/14 20:35, 45F

03/14 20:36, , 46F
另外我剛剛測了一下,在 index 建好的情況下
03/14 20:36, 46F

03/14 20:36, , 47F
27,353,371 筆資料撈特定 sn 的時間 查詢花費 0.0007 秒
03/14 20:36, 47F

03/14 20:36, , 48F
特定一筆 sn
03/14 20:36, 48F

03/14 20:38, , 49F
不過通常 join 的速度不會比較快,這是在我們公司的case下
03/14 20:38, 49F

03/14 20:38, , 50F
測試的結果。當然沒有完全正規化也是影響的因素。
03/14 20:38, 50F

03/14 20:39, , 51F
是說,也許你可以到 database 板問其他前輩們的意見
03/14 20:39, 51F

03/14 21:45, , 52F
應該說是programer會錯亂 管資料庫本身的人應該還好
03/14 21:45, 52F

03/14 21:46, , 53F
所以建議query應該整合並分類成幾個model來用
03/14 21:46, 53F

03/14 21:47, , 54F
資料庫架構有改的話 就統一從model去改 寫程式的只要
03/14 21:47, 54F

03/14 21:47, , 55F
知道他要用什麼function就好
03/14 21:47, 55F

03/15 16:38, , 56F
所以似乎作法還是得看應用在何種情況之下
03/15 16:38, 56F

03/15 16:38, , 57F
並無那個特定的比較好
03/15 16:38, 57F
文章代碼(AID): #1FNsmtxw (PHP)
文章代碼(AID): #1FNsmtxw (PHP)