日志数据库中的主键
我正在创建一个数据库来记录电脑的使用情况。将有几个格式的条目：Computer、User、AuditTime。它用于跟踪执行审核时谁登录到哪台计算机。我们公司及其各自部门的所有计算机和用户的计算机和用户参考表。
我应该将 Computer 和 AuditTime 一起设置为复合键吗？当实际上不需要该表的唯一约束时，是否会因指定主键而造成性能损失或收益？
数据库是MS SQL Server 2008。
I'm creating a database that is going to be logging PC usage. There will be several entries of the format: Computer, User, AuditTime. It is for keeping track of who was logged in to what computer at the time an audit was performed. Computer and User reference tables of all the computers and users in our company and their respective departments.
Should I make Computer and AuditTime together a composite key? Is there a performance hit or gain from bothering to specify a primary key when really, a unique constraint on this table is unnecessary?
The database is MS SQL Server 2008.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
SQL Server 默认将主键设为集群键（除非您明确告诉它不要这样做），正如 Kimberly Tripp 在她的博客文章 聚集索引争论仍在继续，在表上拥有聚集索引对任何操作都有好处 - 包括 INSERT 和 DELETE - 只要它是右类型的聚集索引。
一个好的聚集索引应该是：
最适合的是
INT IDENTITY代理键 - 我建议在绝大多数情况下不要使用复合索引。SQL Server makes your primary keys your clustering keys by default (unless you specifically tell it not to), and as Kimberly Tripp shows in her blog post The Clustered Index Debate Continues, having a clustered index on a table is beneficial for any operation - including INSERT and DELETE - as long as it's the right type of clustered index.
A good clustered index should be:
The best fit would be a
INT IDENTITYsurrogate key - I would advise against compound indices for the vast majority of cases.编辑：投票给Marc_s！
主键会对性能造成影响——这就是为什么它们通常不配置在具有高插入、低读取使用（IE：日志）的表中。但聚集键很好。
Edit: Vote for Marc_s!
There is a performance hit by having a primary key -- that's why they aren't generally configured in tables with high insertion, low reading use (IE: logs). But a clustered key is good.