我有幾個問題，在這裏的SQL大師... 簡而言之，這是廣告管理系統，用戶可以定義不同國家，類別，語言的活動。我幾乎沒有問題，所以請盡你所能幫助我。複雜的SQL設計，需要幫助/建議
通常我使用ASP.NET，並且我想緩存特定用戶的所有結果集，一旦他第一次請求統計信息，這種方式我將避免大型往返服務器。
任何幫助表示歡迎
Click here for diagram你需要我的問題
所有細節 這個應用程序的1.主要問題是展現給用戶多少點擊/印象是，他花了多少錢開展活動。爲他獲取這些信息的最簡單方法是什麼？我還將在此統計表中包含按日期，日期範圍和其他幾個參數進行過濾。
2.其他問題是當用戶嘗試編輯活動時發生的情況。如果用戶將0.01 $設置爲campaignPPU（按設備付費），並且第二天將其更新爲0.05 $，則舊的廣告系列將會消亡，這意味着所有設置都會重置爲0.05 $。
3.如果您可以重新設計表格設計的某些部分，以便修改更靈活，更容易，您將如何做？
謝謝...對不起這麼大的工作，但它可能在這裏
＃1一些感興趣的SQL傢伙，你可能需要使用一系列的視圖來顯示有趣的統計。如果你想緩存結果，你可以將結果存儲到一個報告表，只有每n小時（也許高達每天3或4次刷新？我不知道什麼適合這種情況）。
一旦所有數據都在報告表中，您可以更好地爲其過濾索引，並且由於它將按計劃清除並重新填充，因此訪問速度應該更快。
請注意，如果填充統計信息表不需要太長時間（您將必須是多長時間的判斷）。
對於＃2，這聽起來像是一個潛在的設計問題。 「編輯」是什麼意思？這個編輯操作是否會摧毀舊的廣告系列並創建一個新的「克隆」廣告系列（顯然這不是一個完美的克隆或者不存在問題）？是否有重要的歷史數據，但通過編輯會導致孤兒或刪除？你可能想分析這個「編輯」過程，看看你是否需要添加歷史追蹤到這些表中的一些。也許是一個簡單的日期時間到舊的記錄，或者一個單獨的「歷史」表，它反映了由「編輯」操作修改的表的結構。
對於＃3，它看起來沒問題，但我只看到一個系統的一條細條。我不知道如何應用程序的其餘部分被設計...
@FrustratedWithFormsDes， 1。視圖沒問題，但每次連接都會包含大約5-8個連接，並且具有這種標準化級別。也許你會看到任何方式去規範化表格，以避免5-8加入 2.如果用戶編輯活動，我該怎麼辦。我將無法顯示正確的統計數據，因爲PPU會有所不同。如果我創建另一個表，即。 HistoryOfCampaigns我將需要循環思考版本以獲取當前廣告系列的正確統計信息。 – eugeneK 2010-06-02 14:19:23
@FrustratedWithFormsDes，你能給我一個關於如何設計報表的建議嗎？我還沒有線索。它應該有日期時間，廣告系列狀態，點擊次數和展示次數過濾選項。 – eugeneK 2010-06-02 14:23:18
@eugeneK：報表應包含用戶的統計信息報告所需的列。因此，也許UserID，CampaignID，CampaignName，CampaignDate，AmountSpentToDate（這可能是一個計算列，在數據生成時），...然後，您必須使用所需的數據填充報表。 *許多方式來做到這一點。可以按小時計劃，也可以只按每個用戶進行計劃......最簡單的方法可能是每天一次，在午夜進行一次（如果需要很長時間才能運行）。是的，報表中的數據可能會有點不規範，但沒關係。 – FrustratedWithFormsDesigner 2010-06-02 14:27:35
尤金，
如果您打算保持編輯的活動圍繞考慮不刪除它們。相反，請讓廣告系列的日期更爲敏感例如，用戶A在2010年1月1日開始了廣告系列1，並於2010年2月1日結束，然後在2010年2月2日開始了廣告系列2。
或者如果你不喜歡結束約會你的廣告系列的概念。您可以考慮針對您的廣告系列的歷史記錄表。基本上是相同的表結構，但添加了UniqueIdentifier以使行具有唯一性。
我還應該注意到，這個廣告系列表及其相關表格的估計尺寸對您的設計非常重要。如果您希望只有1000行保留舊錶和當前記錄在一張表中不是問題。然而，如果您計劃擁有100萬個或更多的計劃，那麼您可能希望將舊的和新的分開以便更快地進行查詢，或者在您需要過濾的字段上正確計劃統計數據和指示。還記得indices可用於讀取，但會減慢寫入速度。
我想過歷史表。事情是我設計它沒有意義。 假設ppu或dailyBudget中的每個更改都保存到CampaignsHistory表中，像campaignName這樣的內容不值得在HistoryTable中保存。現在我想知道用戶在某個時間段內花了多少錢。我需要循環思考HistoryTable中與當前活動相對應的所有行，並將該報告生成給用戶。 TBH會導致CPU過載。 我認爲解決這個問題的另一種方式是通過設置parentCampaignID來進行任何與HistoryTable大致相同的更改 – eugeneK 2010-06-02 14:42:50
如果您要以這種方式管理事情，請使用GUID/UniqueIdentifier作爲主鍵。這樣，歷史記錄表中記錄的ID仍然會引用回您的詳細表。注意不要在GUID PK上使用集羣主鍵。這是不是有效的，因爲GUID是不連續的 – 2010-06-02 14:58:50
我應該如何從歷史表和當前表中獲取信息，以便我可以在GUID連接兩者時構建報告？ – eugeneK 2010-06-03 06:03:35
非常好規範化的數據庫... :-) – Lucero 2010-06-02 14:11:37
這是一個非常漂亮的數據庫。但我必須要問的是，單位薪酬的歷史非常重要。您必須能夠追蹤透明或舊廣告系列的每單位付費嗎？ – 2010-06-02 14:13:26
@John Hartsock，PPU非常重要，因爲我會用它來計算用戶花了多少錢，所以如果用戶編輯的廣告系列並將ppu設置得更低或更高，我將無法給他正確的估計值 – eugeneK 2010-06-02 14:21:01