3

我正在设计一个使用SQL Server 2008 R2作为其后端数据库的报表解决方案。数据库模式非常简单。一个名为Calls的表和CallId PK和一个名为Events的表,它具有与fk_CallId调用的外键关联。提高SQL Server数据库性能

每个电话至少有6-7个事件,每天有超过3000个电话登录到db。
我有点担心这个关系对查询的性能有多大影响。如果在超过几百万行的表上使用inner joinEvents)会非常影响性能,我可以将CallerId字段添加到Events表a不使用联接(尽管我将丢失一些其他有关Calls的信息表)。

一般来说,我可以采取其他措施来确保表现良好吗?

+3

经过100年,你的数据库中将有大约1亿行数据,因为这仍然是一个中等规模的数据库,所以我现在真的不用担心性能问题,关键在于确保你已经正确索引您的表格(并在适当的硬件offcourse上运行) – 2012-01-09 08:03:00

+0

@Lieven:感谢您的评论。然而,正如我在奥列格的回答中所评论的那样,我估计每年在“事件”表中估计有7,000,000多行。 – Kamyar 2012-01-09 08:07:44

+3

然后它将在100年后成为7亿行**。我原来的评论仍然适用。虽然我当然鼓励考虑优化,但请确保您不会成为[过早优化]的受害者(http://www.google.be/search?q=premature+optimization&ie=utf-8&oe=utf-8&aq=t&rls= org.mozilla:NL:官方与客户端=火狐-A)。 – 2012-01-09 08:26:31

回答

3

这取决于你的表格如何

其实 - 每天3000个电话是没有这么大的数据,至少在第一个十年8-)

如果你总是想查询所有数据 - 什么是错的由设计的应用和提高性能在一个特定的地方不会治愈所有错误的设计缺点。

的步骤是:

  • 检查正确的索引(至少指数上加入了(和查询)列
  • 检查您的疑问 - 他们给你带来你想要的数据,你唯一想要的数据?
+0

每天3000个电话 - >每天20,000个事件 - >每年超过7,000,000个电话行。 – Kamyar 2012-01-09 08:06:21

+1

那又如何?我使用的数据库从2005年起每天增长150万行,其工作原理类似于具有数亿行和数TB字节数据的魅力。一切都取决于正确的设计 – 2012-01-09 08:11:54

+0

@Kamyar,每年700万行在数据库方面是微不足道的。 – HLGEM 2012-01-09 21:12:26