2011-03-13 54 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