想請教關連性資料庫的設計觀念?

Question

因為自己學php的時間並不是很久

頂多做一些比較簡單不覆雜的後台

現在已經算蠻熟練了

所以想更進一步的學習
不過有一些觀念自己還沒有建立起來
想請教各高手的一些些經驗

讓我比較容易學習+想像

==========================================
請問 資料表中的資料 要達多少筆以上
才會造成搜索資料的困難

假設有5欄好了分別是
sn => smallint , name =>v(20), emil => v(30), tel => v(10), account =>texe
問這一個問題是因為 我一直在想 如果以一個每天有50篇文的論壇來說
我的資料表 有沒有必須依月份來分類 或是依年份咧?
50*365=18250 這樣的資料量 會不會造成搜索時的延遲呢??

基本上希望搜索時間不要超過3秒

===============================================
關連式的資料庫建立的觀念

就以知識+來假設好了

首先有"問題頁"
每一個問題可以也好幾則的"回覆文章"
發問者或回答者的"各人資料"

簡單來說是不是就是建3個資料表呢?

問題資料表 => 記錄發問者 問題 發問時間 問題識別id
回覆資料表 => 記錄回答者 回答 回答時間 相同該問題的問題識別id
各人資料 => 這部份應該就不用幫我解釋了

所以我要問的是 假設今天有1000個問題
每個問題有3個回答

所以 如果
問題資料表有1000筆
回答資料表就有 3000筆嗎
有沒有必要為了減少查詢時間 而有更好的方式呢
如果3000筆的資料 不痛不養
那改成30000000萬筆好了

請問如果資料量這樣大的話
應該如何建立關連式的資料
才能很順的查詢

=============================================
問題很多 也許很基本
但還是麻煩眾高手可以教我一下
給我一個觀念吧><

再補充問一個
假設現在有100人 的會員資料
現在有5個群組 => 需為可變動(新增/刪除 群組)

那資料表應該怎麼設

我自己的想法是
會員資料=>為一個資料表
群組名稱=>為一個資料表
群組會員=>為一個資料表 資料表名稱 同 群組組名稱的資料名稱

在新增 或 刪除群組時 將建立或刪除 群組會員的資料表

也就是說
如果我增加一個叫 knowledge 的群組
將建立一個叫 knowledge 的資料表 負責儲存屬於該群組的會員資料

不知道這樣的觀念 對不對??? 或是應該有更好的做法

to 黑色流星雨

先感謝你的回答
不過有一個問題

會員資料裡面, 有一個很長的文字欄位 ( maybe 255 bytes ), 它可以用來儲存 "以逗號間隔" 的 "所屬群組id",

mabye 應該是 自定欄位名稱 對吧
因為我不記得有叫 mabye的型態

不好意思 因為學的不夠多不夠廣 想確定一下 請別見笑

Answer 1

未雨綢繆喔.. 很好呀!
圖片參考：http://tw.yimg.com/i/tw/blog/smiley/1.gif


不過等您日後真遇上資料庫的效能瓶頸時,就會去尋得更多的解決辦法, 其實方法多到超出想像, 只是.. 急的時候不知道想不想得出來就是了!

您現在先準備方案,以後(甚至平常就設計下去)用到時,才好處變不驚!

資料庫效能的瓶頸最常發生的還是在 programmer 的程式寫法不優造成的... 量要衝破一定的限度才會發生.

( 不優不是不佳, 只是好還可以更好~ )

您自己不就已經提到一種解決方案了嗎? 依據年月來區分!

您可以看看許多線上交易的系統, 例如網路銀行, 它們都只提供一兩個月內的資料供查詢, 為什麼? 就是因為資料量太大了, 一方面儲存空間成本高, 一方面就是查詢速度以及拖垮資料庫整體效能的問題!

當然您都發問了,我卻只有說您的那個方法,那我也太不夠意思了...

不過說真的,這也是技術人面試時常問到的一個問題之一, 都說出來不就影響就業市場... 呵...

有一個很重要的就是 "索引" 的觀念!

索引不只是要您利用資料庫本身的索引功能, 而是索引這個觀念本身! 就以您舉的例子來說好了, 一旦有人發問, 就出現了一個問題識別id, 而與此關聯的資料, 其實可以分散在任何的地方 (資料表, 也不過是一個地方, 這個地方也可以是檔案, 也可以是記憶體, 也可以是另一個資料庫, 也可以是使用者的電腦裡! <--- 扯有點遠了, 但未來或許也會出現 P2P 的資料庫型態 )

假若帶進索引的觀念, 就是只要抽絲剝繭, 用最快速的方式找到資料即可! 例如某一個分類或是某一個日期的資料, 統一放在某處,並透過索引的機制有效率的編排與整理,而問題識別id 能關連到所屬的分類或發問日期, 然後再撈出回答資料! 當資料量越龐大時, 可以考慮越多的層級!

就像您說的 1000 個問題, 底下可能有 3000 個答案.
那好, 我們說發問者交付投票! 所以每個答案都會有他的票數, 每個票數還有可能記載著每個投票者的 id, 時間, IP 位址等... 所以會延伸出 30000 個投票紀錄 (假設平均一個答案得到10票)
看您要怎麼用最快的方法找出它們彼此間的對應!

關聯式資料庫只是資料庫理論的一種.. 其他有興趣您也可研究,但畢竟關聯式資料庫已經能解決超過 90% 以上的問題了, 所以其實已經足夠管用!

說的很籠統.. 我想您應該全都聽懂了.. 至於有緣路過看到的網友,就加減看, 懂多少算是緣分... 剩下的部份是我表達能力不夠好,不是您們的問題... 一_一

-----------------------------------------------------------------------------------------

您提的另一個問題 --> 群組

啊其實您這樣就很好了啊... 通常都是這樣做.

我可以提供其他作法供您參考.

會員資料裡面, 有一個很長的文字欄位 ( maybe 255 bytes ), 它可以用來儲存 "以逗號間隔" 的 "所屬群組id", 簡單來說就是不開三個 table 了, 把群組的資料放在會員資料裡面, 這樣一併取出, 一個 SQL 命令也很方便, 效率也好.

那您說, 反過來可不可以, 把 "屬於這個群組的會員id" 放入群組資料表, OK啊! 就看誰的資料筆數多, 自己斟酌, 不必一定要拘泥於資料庫正規化, 善於變通以因應各種不同的需求, 將可大幅提升系統效能.

有興趣您可研究一下資料庫的查詢成本, 也就是執行每一個不同的 SQL 命令時, 所佔用的系統資源以及耗費時間, 這都是用來評估如何提升系統效能的好方向!
圖片參考：http://tw.yimg.com/i/tw/blog/smiley/5.gif


嗯嗯.. 能這樣發問.. 真是有前途!!

日後發達別忘了提攜小弟我呦~ ^^y

2006-12-23 10:46:03 補充：
maybe ---> 英文字 "也許" 的意思~ 就是 CHAR(255) 或 VARCHAR(255) 都可以囉.