我们正在考虑重组我们的数据库。我们目前列出了大约60,000艘船只跟踪每艘船在几个月内的观看次数。目前的数据库是这样的;
BoatID Year Month Views
1554 2013 2 124
1554 2013 3 1542
我们希望每天在这种结构中存储信息（见下文）这会对数据库产生任何压力吗？（在一年内我们将至少有60,000 x 365 = 21,360,000行）
BoatID Date Views
1554 01/02/2013 20
1554 02/02/2013 142
关于我们的网站 - 我们每月收到大约6,000,000到7,000,000次网页浏览量。我们有一个运行sql2008的专用数据库服务器 - 四核2.2 x 2,24gb内存。
答案 0 :(得分：0)
现有结构的问题在于您只能提供每艘船的视图的高级概述。您只能根据月/年显示视图。如果您希望深入查看数据以查看哪些日期有更多观看次数或活动，则不能。
第二种结构在报告，日期比较等方面为您提供了更大的灵活性。
就查询性能而言，您需要使用执行计划和查询调优来确定查询的执行方式。
答案 1 :(得分：0)
新设计看起来不错。
如果我计算得当，您平均每秒得到的请求少于1。即使我们加倍（有些人在晚上睡觉），这也是每秒2次请求。
我有一种强烈的感觉，你提到的数据库服务器将能够处理它。
一些想法：
检查您的应用程序是否可以缓存视图匹配并执行每次插入/更新，例如10个视图
确保正确索引表格以最大限度地缩短查询时间，更新行只需要很少时间
如果夜间交通流量不足，你可以做一份工作，每天为每艘船插入新的条目;对于重型索引表，插入可能非常昂贵;这是一个想法，我没有测试或使用它，永远......