我想就如何最好地實現我想實現的目標提供一些建議。定期爲定製SQL查詢提供「總計」
我想爲用戶提供一個顯示一個或多個「圖標」（每個說明）並在旁邊顯示總計（有點像iPhone一樣）的屏幕。不要擔心UI，問題不在於此，而在於如何處理後端。
比方說，爲了論證的緣故，我想提供以下幾點：
- 的未讀的記錄總數
- 等待批准預批准
- 總的
- 總數總數批准號碼
- 等...
我想，描述上面最簡單的方法是「MS Outlook」。每當電子郵件到達您的收件箱時，您可以立即看到未讀郵件的數量。我知道它是本地的，所以它有點不同，但現在想象有同樣的原則，但對於上面的查詢。
這可能因用戶而異，雖然動態存儲過程並不理想，但我不認爲我可以爲每個場景編寫一個sp，但同樣，這不是問題。
現在建議部分：
我應該創建一個計時器，每分鐘（比如？）民意調查數據庫，並運行所有的相關的SQL查詢，然後將我提供的相關信息。
是否有一種方法可以在沒有「輪詢」機制的情況下實時執行此操作，即只要查詢發生更改，就會更新總數/計數，然後向相關客戶端推送查詢計數， ？
我是否應該爲每個查詢存儲這些「總計」，並根據SQL中的觸發器立即處理這些更新，然後當用戶查詢時，它只會讀取「總數」而不是試圖計算它們？
與觸發器的問題是，這些都必須單獨定義，我真的很特林保持這一儘可能地通用。再次，我不是關於如何處理這個100％清晰說實話，讓我知道你認爲最好的或者你會怎麼做。
理想情況下，當創建特定查詢時，我想提供選擇。 1）一般（任何人都可以使用這個）和b）具體在哪裏「用戶名」將被用作查詢的一部分，並且返回的計數只會應用於該用戶，但這是另一個問題。
重要的部分實際上是通知部分。雖然投票很容易，但我不確定我喜歡它。
想象一下，如果我有50個查詢要執行，並且我有500個用戶（不太可能，但仍然！）用這些圖標查看屏幕。 500名用戶會每分鐘輪詢一次數據庫，還會執行50個查詢，這可能會導致每個miuntes有25000個查詢......只是聽起來不對。
如上所述，理想情況下，a）我希望能夠實時更改數據，而不必等待一分鐘才能通知新的「計數」，並且b）我想減少查詢到最低限度。也許我不會有選擇。
這個想法背後是，他們將爲每個查詢都有一個小圖標，並且會顯示一個小數字，表示有多少記錄適用於相關查詢。當他們點擊它時，它會給他們帶來相關的結果數據而不是實際的數量，然後可以相應地處理它。
我不知道我是否正確解釋了這一點，但如果不清楚，請詢問，但希望我能得到一些反饋意見。
期待您的反饋。
謝謝。
是不是意圖是非常靜態的意見？目前我們有一個通用的「搜索功能」，可供所有客戶使用，所有客戶都定義了不同的字段，而動態sp不理想，這是我們處理所有情況的唯一方法。我們想要實現的是創建大量的「通知」圖標，這些圖標將顯示有多少記錄與特定搜索匹配並在圖標上顯示總數，因此視圖是否仍屬於該類別？我們絕對不能看到每個「通知」計數圖標情景，因爲這對於所有客戶來說都會有很大不同。 – Thierry
您可以使用以下結構創建視圖：userID，count1，count2，count3，...，count_n。使用創建視圖user_counts作爲select userId，count（distinct ...）。然後將此視圖映射到實體UserCounts並使用該實體顯示用戶圖標。爲了提高性能，您可以爲每個圖標創建一個視圖，但從不爲每個用戶創建一個視圖。 – danihp
我必須進一步研究。它肯定是每個圖標而不是每個用戶的視圖，但雖然不理想，但我仍然希望重新使用我們的動態存儲過程，它負責我們的搜索，但將返回一個計數，但我不確定關於有動態sp的視圖？似乎沒有多大意義。唯一的+，我想是在調用動態sp時，其中的值將被硬編碼，但它只會返回計數而不是實際結果。我真的不知道這是否是一個誠實的加號......正如我所說的，我必須進一步研究它。 – Thierry