2011-03-13 51 views
1

我的應用程序將允許用戶擁有聯繫人列表。這是我目前的架構:數據庫模式,1表或2表

CREATE TABLE IF NOT EXISTS `contact` (
    `id` int(11) NOT NULL AUTO_INCREMENT, 
    `user_id` int(11) NOT NULL, 
    `person_id` int(11) NOT NULL, 
    `create_time` int(11) NOT NULL, 
    PRIMARY KEY (`id`), 
    UNIQUE KEY `user_id` (`user_id`,`person_id`) 
) ENGINE=InnoDB; 

CREATE TABLE IF NOT EXISTS `contact_request` (
    `id` int(11) NOT NULL AUTO_INCREMENT, 
    `user_id` int(11) NOT NULL, 
    `person_id` int(11) NOT NULL, 
    `create_time` int(11) NOT NULL, 
    PRIMARY KEY (`id`), 
    UNIQUE KEY `user_id` (`user_id`,`person_id`) 
) ENGINE=InnoDB; 

CREATE TABLE IF NOT EXISTS `user` (
    `id` int(11) NOT NULL AUTO_INCREMENT, 
    `email_address` varchar(50) NOT NULL, 
    `username` varchar(32) NOT NULL, 
    `password` varchar(32) NOT NULL, 
    PRIMARY KEY (`id`), 
    UNIQUE KEY `email_address` (`email_address`), 
    UNIQUE KEY `username` (`username`) 
) ENGINE=InnoDB; 

當用戶試圖在另一個用戶添加爲聯繫人,記錄在contact_request表中創建。如果接收請求的用戶拒絕該請求,則刪除contact_request記錄。如果用戶決定接受請求,則contact_request表中的數據將添加到聯繫人表中,然後從contact_request表中刪除。

我意識到我可以通過另一種方式做到這一點,我刪除contact_request表並添加另一個字段到聯繫人表例如:狀態,表示聯繫人是否剛剛被請求或者它是否是一個接受的請求。

CREATE TABLE IF NOT EXISTS `contact` (
    `id` int(11) NOT NULL AUTO_INCREMENT, 
    `user_id` int(11) NOT NULL, 
    `person_id` int(11) NOT NULL, 
    `status` tinyint(1) not null, 
    `create_time` int(11) NOT NULL, 
    PRIMARY KEY (`id`), 
    UNIQUE KEY `user_id` (`user_id`,`person_id`) 
) ENGINE=InnoDB; 

我看到的好處是我會有1個表少。我目前沒有看到由於這種改變而發生的問題。這值得改變嗎?我可能沒有意識到哪種方法還有其他優點?建議哪個?

回答

0

從某種意義上說,將它們作爲兩個表格會更清潔。您可以清除並保持小表queue,同時不必過濾掉非真實聯繫人。這聽起來像你永遠不會真的需要在同一個表中查看聯繫人和請求,所以沒有理由將它們混合在一起,僅僅是爲了它。

另一方面,我可以看到的唯一的優點是,你在數據庫中只有一個表嗎?一個非常模糊的不能意外地有一個聯繫人同時存在於聯繫表本身和請求表中(計時錯誤或其他)。

+0

我想我應該提到我會同時顯示聯繫人和聯繫請求。我決定改變它使用單個表格,如果我有任何問題,請回復。謝謝您的回答。 – 2011-03-14 18:48:14

1

這是值得改變的原因不止一個;正如你所說的那樣,它可以讓你減少一張桌子。但更重要的是,它將允許您避免人們請求與已經添加的人聯繫,而無需查詢額外的表格。

+0

「這將允許您避免人們請求與他們已經添加的人聯繫,而無需查詢額外的表」這是+ – 2011-03-14 14:31:38

2

另外一個好處可能是有這個status(無論是作爲INTCHAR),記錄請求(Q),接受觸點(C),被拒絕的請求(J),拒絕和重新請求(R),列入黑名單(B)以及其他可能的狀態,以便您可以更輕鬆地應用更復雜的邏輯,例如「用戶在拒絕兩次後不能再請求聯繫」等。

+0

謝謝。我目前不使用這種邏輯,但如果我決定實施它,我肯定會發現這種方法的用處。 – 2011-03-14 14:30:34