SQL社交网络,正确的方式来保持消息?

问题描述:

我正在建立一个社交网络,现在我面临一个问题。SQL社交网络,正确的方式来保持消息?

那么,哪一个是更快(保持消息):

每个新用户有一个数据库, 并创建新表(的消息)?

像这样:

CREATE DATABASE 'user_messages'; 

CREATE TABLE 'user_id' (

    id int(32) NOT NULL PRIMARY KEY, 
    new ENUM ('Y', 'N') NOT NULL DEFAULT 'Y', 
    time timestamp NOT NULL, 
    from_id int(32) 
); 

OR,

要将所有邮件保留在一个单独的表(带复制)??? (使用INDEXes) 如果有数十亿行会怎么样? 像这样:

INSERT INTO 'user_messages' (id, new, time, from_id) VALUES ('id_value', 'Y', now(), 'friend_id'); 

创建每个用户一个表将成为一场噩梦,而无需使用动态地生成的SQL所有的时间来查询。

一个更好的选择是创建一个单独的表,并将该表中的所有用户的所有消息与外部密钥一起存回用户表中。外键将被编入索引,并且不应该有大量的性能问题。如果你要有数十亿行(或消息),那么你的数据库架构应该相应地缩放以处理这些数据量,但是你的数据库设计不应因此而改变。

+0

并索引它... – 2012-02-14 10:25:25

那么,哪一个是更快(保持消息):

它可能既不是快,但我怀疑SQL Server对表的上限是显著小于它的上限行。而且我不知道你是否因跨越不同数据库的交易而出现一些滑溜溜的表现。

正确的数据库设计将决定单个表。

(使用INDEXes)如果有十亿行呢?像这样:

那么,也许你应该得到10亿行,然后再开始解决这个问题。但请注意,出于多种原因(通常为了提高性能),您可以对数据进行分区(Google SQL Server表分区)。