2010-07-29 83 views
0

我正在構建一個Web應用程序,它將(理想情況下)允許用戶關注討論主題(其格式爲Q &),還可以遵循其他內容類型,例如公司和學校有個人資料頁面。 (該網站旨在幫助專業求職,所以後端爲企業,學校等提供了一個簡單的個人資料頁面)適用於以下多種內容類型的MySQL結構

有一個「關注」表是否更有效率?有一個follow_entity_type字段,可以訪問並重定向到相應的內容表(Q & A,公司等)?或者當我嘗試編譯用戶的提要時,是否需要爲每個需要單獨訪問的內容類型設置一個「關注」表?第一個似乎需要更復雜的編碼和查詢,而第二個則會使按時間順序組織所有類型的帖子更加困難。

我確定解決方案很簡單,但作爲兼職開發人員和自動裁決,有時候我會錯過基本知識。

回答

0

我會最多follow_entity_type字段。在我看來,從實體列表中集成一種額外類型的提取然後在列表的所有實例中集成新的聯合表格變得更加容易。這也意味着每個'內容類型'只需要添加1個而不是2個表格,其中存儲&檢索已經被處理。查詢並沒有得到那麼多的恕我直言。

+0

感謝您的建議!我沿着同樣的思路思考。 – tchaymore 2010-07-29 22:29:35

1

想想你會如何在面向對象設計中做到這一點:你可以有一個共同的超類或接口,用於可以遵循的所有類型的事情。稱它爲Followable

interface Followable { } 

class QandA implements Followable { ... } 
class Profiles implements Followable { ... } 

然後,當你代表「隨動」對象的集合,可以確保集合包括針對$object instanceof Followable是真實的對象。

你可以做同樣的事情與SQL表:

CREATE TABLE Followables (follow_id INT AUTO_INCREMENT PRIMARY KEY ...); 

CREATE TABLE QandA (qanda_id INT PRIMARY KEY ... , 
    FOREIGN KEY (qanda_id) REFERENCES Followables(follow_id)); 
CREATE TABLE Profiles (profile_id INT PRIMARY KEY ... , 
    FOREIGN KEY (profile_id) REFERENCES Followables(follow_id)); 

我們的事情你引用的用戶接踵而來的是一個外鍵Followables

CREATE TABLE UserFollows (
    user_id INT NOT NULL, 
    follow_id INT NOT NULL, 
    PRIMARY KEY (user_id, follow_id), 
    FOREIGN KEY (user_id) REFERENCES Users(user_id), 
    FOREIGN KEY (follow_id) REFERENCES Followables(follow_id) 
); 

Class Table Inheritance見。

+0

我喜歡這個設置,但是我們不會讓用戶也跟隨它的原因是什麼? – Wrikken 2010-07-29 22:37:11

+0

你可以做任何事情,我只是展示了兩個例子。 – 2010-07-30 00:32:48

+0

檢查,那裏沒有問題,很好。 – Wrikken 2010-07-30 16:37:00

相關問題