為通用對象實現數據庫結構

Question

我正在建立一個PHP / MySQL網站，目前正在從事數據庫設計工作。 我確實有一些數據庫和MySQL的經驗，但是我從來沒有為一個現實的應用程序從頭開始構建一個數據庫，希望它會帶來一些良好的訪問量，所以我很想聽聽已經這樣做的人的建議，以避免常見錯誤。 我希望我的解釋不要太混亂。

我需要的

在我的應用程序中，用戶應該能夠編寫帖子（標題+文字），然后創建一個“對象”（可以是任何東西，例如視頻或歌曲等）並將其附加到帖子上。 該站點提供了用戶可以創建的預定義對象類型的列表，將來我應該可以添加新的類型。 用戶還應該能夠在專用頁面中查看對象的詳細信息並為其添加注釋-帖子也是如此。

我嘗試了什么

我用以下字段創建了一個objects表： oid ， type ， name和date 。 該表包含用戶應能夠向其添加注釋的任何內容（即帖子和對象）的記錄。 然后，我創建了一個postmeta表，其中包含其他發布數據（例如文本，作者，最后編輯日期等），一個videometa表，用於存儲有關“視頻”對象（URL，描述等）的數據，等等。 postobject表（ pid ， oid ）將對象鏈接到帖子。 此外，還有一個comments表，其中包含注釋文本，作者及其引用的對象的ID。

由於對象類型的列表是預定義的，並且可能不會更改（盡管我仍然需要隨時可以在不更改應用程序代碼結構或數據庫設計的情況下輕松添加類型的能力），並且它相對較小，因此不是為每種類型創建“元”表並在我的應用程序中創建相應的PHP類來處理該表的問題。

最后，該站點上的頁面需要顯示所有帖子的列表，包括按其日期排序的所有附件，包括附加到該對象的對象。 因此，我從objects表中獲取所有類型為“ post”的記錄，並將其與postmeta合並以獲取發布元數據。 然后我查詢postobject讓所有連接到這個職位的目的，並comments讓所有的評論。

問題

這有意義嗎？ 以這種方式為現實世界的網站設計數據庫有什么好處？ 我需要聯接很多表來獲取所需的所有數據，而objects表將變得非常龐大，因為它幾乎包含了每一項（雖然只包括類型，名稱和創建日期）-這是為了保留數據庫和應用程序代碼靈活，但是它可以在現實世界中運行，還是從長遠來看太昂貴了？ 我是否用這種OOP方法以錯誤的方式思考它？

更具體地說：假設我需要列出所有帖子，包括其附加的對象和元數據。 我至少需要加入這些表： posts ， postmeta ， postobject和{$objecttype}meta （例如，不用說一個users表來獲取特定用戶的所有帖子）。 即使僅使用數字索引，這樣做也會導致性能下降嗎？

另外，我考慮為該項目使用NoSQL數據庫（MongoDB）（感謝Stuart Ellis的建議）。 顯然，這似乎更合適，因為我在這里需要一些靈活性。 但是我的疑問是：我對象的元數據包含許多對數據庫中其他記錄的引用。 那么，如果我不能使用JOIN該如何避免數據重復？ 我應該使用DBRef和此處描述的技術嗎？ 在性能方面，它們與上述結構中使用的MySQL JOIN相比如何？

我希望這些問題確實有意義。 這是我的第一個此類項目，我只是想避免在啟動它之前犯下大錯，並發現我需要完全重新設計。

Answer 1

我不是NoSQL專家，但我想知道這種特殊情況是否真的可以通過文檔數據庫（MongoDB或CouchDB）得到最好的處理。 各種類型的帶有元數據附加的對象聽起來像MongoDB設計用於的場景。

FWIW，您的表和字段命名存在一些問題，以后可能會困擾您。 例如，類型和日期是相當通用的，也是保留字。 您還混合了單數和復數表名，這將引發任何自動對象映射。

無論使用哪種數據庫，最好找到一組現有的數據庫命名約定並從一開始就應用它-這將幫助您避免細微的問題並確保命名保持一致。 我傾向於使用Rails命名約定ATM，因為它們眾所周知且相當明智。

Answer 2

或者，如果您擔心數據庫空間，則可以將對象內容存儲為文件，位於數據庫外部。

如果您存儲任何東西在數據庫中，你已經在對象類型objects ; 因此，您可以只添加帶有長二進制字段的object_contents表來存儲對象。 您無需為每種新類型創建一個新表。

Answer 3

我已經在現實世界的Web應用程序中看到了很多JOIN（5到10）。 對象表可能會變大，但這只是索引。 到目前為止，您的數據庫中沒有發現任何錯誤。 順便說一句，什么讓我感到奇怪-一個帖子，一個對象以及每個單獨的注釋？ 無法將圖片與文字混合？