2009-12-01 22 views
0

我正在構建一個報告應用程序,因此我正在處理大量的數據。我以靈活的方式創建應用程序的一部分方法是使用SQL視圖消除數據庫的壓力,如果多個用戶都在匆忙中。2個部分的SQL故事 - SQL視圖總是很好,我該如何解決這個例子?

一個例子是:

mysql_query("CREATE VIEW view_silverpop_clicks_baby_$email AS SELECT view_email_baby_position.EmailAddress, view_email_baby_position.days, silverpop_campaign_emails.id, silverpop_actions.`Click Name` , silverpop_actions.`Mailing Id` 
FROM silverpop_actions 
INNER JOIN view_email_baby_position ON (silverpop_actions.Email = view_email_baby_position.EmailAddress) , silverpop_campaign_emails 
WHERE silverpop_campaign_emails.id = $email 
AND view_email_baby_position.days 
BETWEEN silverpop_campaign_emails.low 
AND silverpop_campaign_emails.high 
AND silverpop_actions.`Event Type` = 'Click Through'") or die(mysql_error()); 

再後來在腳本這一觀點被用來計算點擊該電子郵件的特殊風味已數。

$sql = "SELECT count(*) as count FROM `view_silverpop_clicks_baby_$email` WHERE `Click Name` LIKE '$countme%'"; 

我的問題是兩個部分真:

  1. 是意見總是好的?你能 有太多?
  2. 我可以創建另一組 視圖來緩存 中的count變量的第二個代碼片段。如果是的話 我怎麼能這樣做呢?我不能 相當這樣做。

謝謝!

+1

由於很多用戶的意見,視圖將不會消耗DB的任何壓力。 它只是一個邏輯結構來隱藏查詢的複雜性。 – Khb 2009-12-01 11:41:55

+0

我的觀點被緩存 - 這意味着它們加速數據交付的速度非常快嗎? – MrFidge 2009-12-01 11:43:12

+1

查詢執行計劃被緩存而不是數據本身。要緩存數據,您需要索引或物化視圖。 – Goran 2009-12-01 11:52:40

回答

4

回答你的問題。

1.)我不知道我能想到一個實例,其中的視圖和BAD本身不一樣,但不必要地使用它們會很糟糕。你是否可以有太多的事情取決於你的情況。

2.)擁有另一組視圖不會緩存count變量,因此從這個角度來看它不會有好處。

話雖如此,我認爲你對某種觀點實際上有什麼誤解。視圖只是特定SQL語句的定義,並不會緩存數據。當您執行SELECT * FROM myView;時,數據庫仍在執行CREATE VIEW定義中定義的select語句,就像用戶執行該語句時一樣。

某些數據庫供應商提供了一種稱爲物化視圖的不同類型的視圖。在這種情況下,創建視圖所需的表數據將被存儲/緩存,並且通常基於創建時指定的刷新率進行更新。從數據存儲兩次的意義上來說,這是「沉重的」,但是可以創建更好的執行計劃,因爲數據已經被加入,彙總等等。但是請注意,您只能看到基於物化視圖的上次刷新的數據,在普通視圖中,您可以看到當前存在於基礎表中的數據。目前,MySQL不支持物化視圖。

的觀點一些有用的用途是:

  • 創建複雜的查詢更容易/清潔SQL語句(這是你正在做的)

  • 安全。如果您希望用戶能夠看到某些列或行,而不是其他列或行,則可以限制對基本表的訪問並創建基表的視圖,該表只會選擇列/行用戶也應該有訪問權限。

  • 創建表

1

視圖用於通過查詢優化,使他們常常在更有效地查詢信息幫助的聚合。

但是,索引或物化視圖會創建一個包含所需信息的表格,這可能會產生很大的差異。把它看作是你的數據庫方案的非規範化,而不改變現有的方案。你兩全其美。

  1. 一些意見從不使用,因此它們代表了針的強制性 - 這是不好的。
  2. 索引視圖不能引用其他視圖(mssql),所以創建這樣的視圖幾乎沒有意義。