沒有介紹耶，大家自己想吧
其實這樣技術當天就寫出來了，花了3個小時去實做出來，想法如下：當使用者下條件的時候，有可能會拉出很多筆資料，資料量可能會到幾千幾萬，傳統的作法是，全部撈出來，放在記憶體裡面，然後，挑選要看得資料，接下來修改『那一筆』資料，回存資料庫。這個作法當然是好，既安全又可靠，可是，每次都撈一大堆，實際上要看得就那幾筆，浪費不只記憶體空間，網路傳輸也是一項負擔，當然，可以叫客戶全部買G等級的網路，然後賣一堆設備賺錢，可是，身為程式設計師，難道每次都要靠硬體？沒有我們自己的想法嗎？有的，動態查詢專門解決這一項問題，只撈出『螢幕顯示』的資料，同時用SQL去算出一共有幾筆，再記憶體制造出虛擬的資料量，同時餵給DataGridView或是GridView不管。。。。重點是，如果螢幕一次只能顯示10筆資料，客戶所下的條件可能會查出500筆，程式就只撈1~10筆，當然有人會反應，這樣DataGridView不是就沒有上下捲軸了？當然有解，下一個動作是用SQL去算出一共有幾筆，扣掉目前有的筆數，用迴圈填入空白的ROW，這樣一來，客戶端『看』起來有500筆，實際網路傳輸的時候只有10筆，當客戶端滾動捲軸，準備要看到空白的ROW的時候，再去撈11~20的資料，替換掉空白的ROW，使用者會覺得程式很順，硬體完全沒有負擔，實際上，程式設計師的演算法解覺得這一項問題。。。。。程式有興趣自己跟我要Windows版跟Web版都有
其實這樣技術當天就寫出來了，花了3個小時去實做出來，想法如下：
回覆刪除當使用者下條件的時候，有可能會拉出很多筆資料，資料量可能會到幾千幾萬，傳統的作法是，全部撈出來，放在記憶體裡面，然後，挑選要看得資料，接下來修改『那一筆』資料，回存資料庫。
這個作法當然是好，既安全又可靠，可是，每次都撈一大堆，實際上要看得就那幾筆，浪費不只記憶體空間，網路傳輸也是一項負擔，當然，可以叫客戶全部買G等級的網路，然後賣一堆設備賺錢，可是，身為程式設計師，難道每次都要靠硬體？沒有我們自己的想法嗎？有的，動態查詢專門解決這一項問題，只撈出『螢幕顯示』的資料，同時用SQL去算出一共有幾筆，再記憶體制造出虛擬的資料量，同時餵給DataGridView或是GridView不管。。。。重點是，如果螢幕一次只能顯示10筆資料，客戶所下的條件可能會查出500筆，程式就只撈1~10筆，當然有人會反應，這樣DataGridView不是就沒有上下捲軸了？當然有解，下一個動作是用SQL去算出一共有幾筆，扣掉目前有的筆數，用迴圈填入空白的ROW，這樣一來，客戶端『看』起來有500筆，實際網路傳輸的時候只有10筆，當客戶端滾動捲軸，準備要看到空白的ROW的時候，再去撈11~20的資料，替換掉空白的ROW，使用者會覺得程式很順，硬體完全沒有負擔，實際上，程式設計師的演算法解覺得這一項問題。。。。。程式有興趣自己跟我要Windows版跟Web版都有