数据库表PK

时间:2010-10-21 16:08:45

标签: sql create-table

我有一个表格,用于存储用户用户的评论。我将有1亿条评论。

我可以通过两种方式创建它:

选项1:用户名和评论ID为PK。这样,所有注释都按用户名和注释ID进行物理存储。

CREATE TABLE [dbo].[Comments](
    [user] [varchar](20) NOT NULL,
    [com_id] [int] IDENTITY(1,1) NOT NULL,
    [com_posted_by] [varchar](20) NOT NULL,
    [com_posted_on] [smalldatetime] NOT NULL CONSTRAINT DEFAULT (getdate()),
    [com_text] [nvarchar](225) COLLATE NOT NULL,
 CONSTRAINT [PK_channel_comments] PRIMARY KEY CLUSTERED 
 ([channel] ASC, [com_id] ASC) WITH (IGNORE_DUP_KEY = OFF) ON [PRIMARY]) ON [PRIMARY]

优点:我的查询将通过comment_id DESC获取用户订单的全部或前10条评论。这是SEEK

选项2:我可以将评论ID作为PK。这将存储按注释ID排序的注释,而不是用户名。

缺点:获取给定用户的最新前10条评论不再是因为用户未存储的数据(即未按用户排序)。所以我必须创建其他索引来提高查询性能。

哪种方式是最好的方法? 插入和删除怎么样?允许这些操作。但经常阅读。

用户无法修改他们的评论。

我用1.1M行测试了两个表。结果如下:

table_name  rows        reserved    data        index_size  unused
comments2   1079892     99488 KB    62824 KB    36576 KB    88 KB  (PK: com_id  Second Index on (user_name, com_id))
comments1   1079892     82376 KB    82040 KB    328 KB      8 KB   (PK: user_name, no other indices)
--------------------------------------------------------------------
diff:       same rows   17112KB     -19216KB    36,248KB    80KB

因此,使用com_id作为PK的表仅为2索引使用36MB额外磁盘空间 使用SEEK在两个表上选择顶部查询,但使用com_id作为PK的表更慢 但是当我把com_id当作PK

时插入会稍快一点

有任何意见吗?

5 个答案:

答案 0 :(得分:2)

我会使用Comment ID作为表的主键。如果您要使用注释ID和用户名进行大量查询,那么在这些字段上添加索引可能更简单。

答案 1 :(得分:0)

我不会在PK中使用用户名,因为它可能会更改,稍后会创建级联更新问题。 此外,将这两者连接到PK中会创建一个大(r)PK,可能必须作为FK传递给其他表。我尽量保持PK显示为尽可能小的FK,除非我知道我会想要一个大键中的贡献表的所有PK以提高查询速度。 评论ID应该没问题。 您可能需要创建一个附加索引,以便快速搜索注释ID和用户名。 你会做更多的插入/更新或查询吗?如果查询密集,则索引不是问题。

答案 2 :(得分:0)

您确定您的CREATE TABLE语句正确吗?你在PK定义中使用[Channel],我不认为它是一个列。你的意思是[用户]。

你在某个地方有用户表吗?如果是这样,您可以通过在整数值上键入并将UserID放入评论表而不是用户来节省大量开销。

我会在CommentID上PK,然后在[UserID,CommentID]上添加非聚集索引。这使您可以通过ID(删除等)立即访问注释,而无需在WHERE子句中涉及UserID值;它可以快速访问用户的评论。但是,我并不倾向于使用您预期的尺寸表。

答案 3 :(得分:0)

根据经验,总是选择最窄的PK。然后,为了提高性能,您可能希望使用基于整数的User_id而不是varchar,并为这两列添加索引。

最佳方法取决于用户数量,如果只有少数用户,则commet_id user_id pk可能更好(另外,用户可以选择分区);另一方面,如果用户数量很高,合并的Pk将无用。

答案 4 :(得分:0)

我最初的方法是单独将CommentID设为PK,可能按降序排列,这样您就不必对select进行任何重新排序。然后在UserID上放一个索引。

如果使用连锁密钥,请考虑将CommentID切换为desc。