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