write - w3c php mysql




你將如何構建一個論壇的數據庫模式? (5)

我正在建立一個實踐的小論壇。 我發現像phpBB這樣的論壇將線程文本存儲在單獨的表中。

為什麼? 為什麼不把它們全部存放在同一張桌子上?

例如: thread_id, thread_date, thread_text, thread_author

為什麼這樣做? 你會怎麼做?


InnoDB不支持FULLTEXT索引, MyISAM不支持事務。

不知道phpBB ,但可能這就是為什麼他們分開表格。


一方面,大多數關係型數據庫的文件系統佈局是這樣的,即存儲大塊任意文本或數據會使系統變慢。 由於數據通常是按行存儲的,因此在執行搜索時,即使查找不相關的字段,數據庫現在也必須跳過可變長度的文本字段。

其次,如果每個thread_id都需要更多的數據,那麼將所有內容放在一張表中會使後面添加數據模型變得更加困難。

很好地設計數據庫模式需要一些教育。 你應該從http://en.wikipedia.org/wiki/Database_normalization開始。 一定要理解第三範式。


我實際上並不知道為什麼這樣做,但我可以想像的一個原因是優化後期元數據(日期,作者等)的搜索和檢索。

根據Joel的說法 (Joel總是正確的!-)數據庫將數據存儲在固定長度記錄中的固定長度字段中,因此只需將指針增加一個字節長度就可以輕鬆地從一行跳到下一行記錄。 但用於存儲發布文本的大型文本字段不能具有固定大小,因為帖子的長度在很大範圍內變化,並且創建足夠大的固定長度存儲以容納所有帖子會浪費大量空間。 這意味著,如果想要檢索大量帖子的元數據,將發布文本存儲在同一張表中,而其他信息會使其慢得多,就像每次有人查看主論壇頁面時所做的那樣。

獲得兩全其美的方法是將固定長度的字段(即除發布文本以外的所有內容)放在一個表中,並將可變長度的字段(即發布文本)放在另一個表中。


由於表格可以到達的大小,它們不會將文本存儲在同一個表格中。

這樣,即使有很多條目,線程列表也很小,索引很好,掃描速度也很快。 僅在必要時才使用主鍵訪問文本,該主鍵也很快。

對於小型論壇,我認為這不是必須的,因為有一點編碼開銷。








structure