我有大型數據庫，其中包含數千條記錄，我需要每週查詢這些記錄。然後我必須使用訪問報告創建這些數據的摘要。當我第一次創建數據庫時（我最近做過），我創建了幾種類型的查詢（大約80），然後創建子報表，然後將這些子報表放在一個巨大的主報表中。80查詢太多了嗎？
我從來沒有使用數據庫之前，並告訴我，也許我不應該有80個不同的查詢，填充80個不同的子報表。我不知道，也許沒關係。但是，這是我的問題，是否有任何理由回去重做一些這些查詢，並將它們合併到20或30（這將要求我重做子報告和主要報告），或者完全沒問題有這麼多的查詢保存在我的數據庫中。請記住，每個查詢雖然每個查詢只包含2個或3個函數，但有一個非常具體的任務，我無法完全擺脫它，但我只能通過組合幾種類型將這些函數添加到更大的查詢中的查詢。另外，正如我所說的，我必須每週使用這些查詢，所以我不想像某些人選擇那樣快速構建它們。
不管怎麼說，有一些無法預料的問題，我有這麼多的疑問，缺少或這是正常的嗎？
如果它滿足您的要求（即「足夠快」）並且不妨礙其他人（即不會減慢其他人的速度），那麼它應該沒問題。
我只是確保所有查詢都能夠針對您的目標數據集單獨運行。它在開發過程中可能對50行有很大的幫助，但生產中有1M行。
但是，如果它在生產數據庫上的運行速度足夠快，那麼可以使用它來解決另一個問題。
如果您想從中學習經驗，那麼將其應用於未來的項目，而不是重新鋪設剛鋪設的道路。
+1;並確保你的未來數據，並預測增長。不要只是做今天的負載，嘗試超過目標負載的時間代碼量預計將停滯不前。 –
不知道所有的細節，不可能回答你是否應該有20或80或200個查詢。但是，增加查詢並不會損害任何內容，並且作爲一般數據庫問題，最好讓您的查詢專注於他們特別需要的內容，而不是讓少量返回更多的「通用」查詢數據超過了真正的必要。
如果您的查詢次數較少，而且您需要更改報表/查詢以顯示其他數據，那麼您可能必須返回並重新測試所有依賴於相同查詢的數據確保他們沒有被改變打破。
+1但是，代碼重用不是一種好的做法嗎？ ; =） –
@Itay Moav在查詢數據庫時重複使用代碼經常會導致性能問題，因此，除非您正在重用的代碼完全符合您正在解決的問題，否則並非總是一種好的做法。通用查詢或更糟糕的一個動態查詢構建來處理所有事務可能會導致數據庫性能下降，因爲它會優化錯誤。進一步重用發送比此過程所需字段更多的字段的現有代碼會浪費數據庫和網絡資源。 – HLGEM
這是一個報告。在數據庫中有80個查詢並不是那麼糟糕。有80個查詢一個報告...
如果表現不是問題，那麼你可能沒有問題。
做一些這些查詢返回基本相同的列信息，但具有不同的結果？如果是這樣，請研究重構您的查詢以使用參數。
對於查看參數化查詢的建議+1。 –
那（參數化）如何轉換成報告中使用的查詢？當您的SQL與Access中的報表/表單一起使用時，參數比它們值得的更麻煩。從優化或性能的角度來看，他們確實沒有做太多的事情。 –
爲什麼需要保存查詢？您可能會有很多報表/子報表，但您可以將SQL SELECT保存爲相關報表的記錄源屬性，而無需將SQL保存爲已保存的查詢。
我儘量減少保存的查詢數量，因爲你擁有的數量越多，追蹤它們的難度就越大。然後你最終需要想出一些命名約定，這樣你就可以知道什麼是什麼，然後最終你會陷入一團糟。
此外，重複使用不是這樣做的理由。通常，重用對象是很好的做法，但保存的QueryDefs的問題是沒有簡單的方法來測試依賴關係（儘管如果你打開Name AutoCorrect，你可以看到使用查詢的位置）。因此，如果您重新使用查詢來更改一個上下文，而這個上下文會在其使用的其他上下文中中斷查詢，那麼這很容易。因此，一般來說，除非所涉及的數據集真正在100％的時間內完全相同（例如，呈現完全相同數據的表單和報表），否則我不會重複使用已保存的查詢。因此，基本上，我會說80個保存的查詢在體面大小的應用程序中沒有什麼大不了的，但從您所描述的內容來看，我沒有看到爲什麼SQL應該存儲在保存的查詢中。在這種情況下，ZERO保存的查詢將是適當的數字。
看到我最近的帖子上關於Query Design Practices in SQL的問題。
問題「太多了」的問題是它是主觀的，答案只會是粗略的估計，在大多數情況下完全和完全錯誤。以準確的負載情況進行負載測試，並確定它是否「太多」。或者等到你知道它沒有被訪問（例如停機時間）來生成你的報告，並且通過抖動數據庫去狂野吧:) –