的一切，是不是標有「計算」或「最終值」是原始數據，我會被操縱。
我終於知道足夠的SQL能夠創建必要的表並執行所需的計算。但是，我只是想驗證沒有更簡單的方法來做到這一點，這將涉及更少的表。
創建視圖而不是實際更改表格並插入計算列會更好嗎？在表3中有最終數據後，我並不關心Table1和Table2中的計算列。 SQL Server 2008.
我還應該注意到，我將每天接收Table1和Table2的新原始數據，並且計劃追加這些記錄，然後將新的最終值附加到Table3以及日期字段。
從這裏開始： http://support.microsoft.com/kb/283878
你永遠不希望直接存儲在計算表，計算將被生成數據查詢來完成。表3實際上是一個簡單查詢的結果。
從你有什麼上面，我會說你至少有以下三個表：
客戶 - 包括客戶的基本資料，每個客戶一行，並某種ID，你生成（可能是一個整數標識列是最好的，但可以是您選擇的任何東西）。
產品（或產品，如果您的水果和蔬菜不止一種） - 每個產品包含產品信息一行，您生成某種類型的ID（同樣，整數身份是最好的）。
銷售 - 每筆交易一行
這裏有些棘手的地方。您可以擁有Sales和SalesItems，其中銷售對於每個交易具有唯一的行，並且SalesItems對於在交易中購買的每個產品都包含一行，但對於上面顯示的非常簡單的系統，您可以使用具有ProductID和CustomerID以及數量和您想要存儲的任何其他商品的銷售表。
編輯：這是一個安全的賭注，一個簡單的系統將有一天會成長爲一個複雜的系統，所以如果我設計的數據庫，我可能會去銷售和SalesItems單獨的表，使數據庫更靈活，能夠規模更好。
謝謝。我認爲這很有道理。最後，我最關心的是跟蹤團隊的表現，比如「水果」與「蔬菜」相比的表現。客戶的細分不是主要目標。 – eek142 2012-02-08 17:05:54
是的，我聽說過，我剛剛去過很多客戶，他們站在數據庫上解決了一個小問題，並且在他們知道它已經成長爲最重要的應用程序之前。在將來的某個時候，你永遠不知道你是否會對哪些顧客購買最多的水果與蔬菜或類似的東西感興趣。將設計規劃出來，使其能夠在未來擴展到其他要求總是不錯的。 – 2012-02-08 17:11:49
當你說你永遠不想直接在表格中存儲計算數據時，你的意思是我應該爲這些數據創建一個單獨的表格，或者有一些方法可以在表格3中生成值，而不必將計算列存儲在表1和表2？ – eek142 2012-02-08 19:20:53
任何時候你正在考慮動態地向SQL添加表/列，你100％做錯了（呃，也許99.9％，但仍然！） – Jamiec 2012-02-08 16:34:16