在這篇文章中，將會列出10個常見的需要避免的查詢設計錯誤。閱讀此文，確保你不會成為這些錯誤的受害者，考慮給出的建議，修改你的查詢。
1、數據模型和並發查詢
如果你在構建數據模型的時候沒有考慮到數據的訪問方式，將會導致難以處理的查詢。你可能會用到根本不必要的JOIN增加代碼，損害性能。
要糾正這個問題，考慮一下需要訪問數據的查詢。如果查詢在這個處理階段不是很清晰，那麼將來在寫代碼的時候就會更困難。很有可能是數據庫設計過於復雜，可以通過簡化來改善查詢的性能。
與此相關，如果你是個喜歡直觀的人，那麼就打印出數據模型，或者在你選擇數據建模工具的時候查看一下在線的模型。這可以改善你的代碼時間和精確性。
2、什麼是最好的技巧?
這就是聲名狼藉的指針與基於集合的邏輯討論。傳統的至理名言說，對所有的數據庫訪問都使用基於集合的邏輯。一般來說，我同意這是最好的經驗之一。當基於集合的邏輯是正確的選擇的時候，卻使用了指針，可能會對性能產生很大的損害。SQL Server的設計是使用基於集合的邏輯，並且在大多數處理中應該使用它。
事分兩面，另一面就是指針的例子。在這種情況下，指針邏輯勝過基於集合的邏輯。從這個信息引申出來的結論就是，判斷你要執行的處理的類型，選擇最適合需要的技巧。
3、以原有的方式……
SQL Server 2005為你的查詢提供了一整套新的機會。所以使用老的辦法可能仍然會起作用，但是也是時候去考慮一下最新的選擇了。TRY…CATCH錯誤處理方法是你最先應該使用在代碼中的技巧之一。此外還要考慮的是對層次進行處理的時候，可以用到通用表壓縮;最後一項考慮是擴展關系型數據庫引擎的功能:通用語言運行時(CLR)。這三項技術都在極大程度上改變了你使用SQL Server工作的方式，而它們只是冰山一角。
4、你還讓一只笨鵝在那裡嗎?
檢查你的代碼，然後安排一個時間進行同樣的查看，這是在部署代碼之前必須要做的事情。檢查你的代碼，明確查詢計劃，是確保使用了合適的索引，並且查詢會像你期望的那樣運行的重要保障。
5、這是經典錯誤
輸入SELECT *語句，想著表永遠不會改變，這是一個經典的查詢設計錯誤。即使在最簡單的解決方案中，表的改變也是不可避免的，你需要查看代碼確保沒有包含一個額外的字段。或者，更糟糕的是，你必須等待應用程序崩潰，然後修正這些問題。最好的實踐方案只是在你的查詢中包含進來你需要的那些字段，然後必要的話就修改它們。不要把你的時間浪費在四處冒煙的模式中徹查代碼。
6、我沒有注釋
不幸的是，我見過的大多數代碼都很少或者根本沒有注釋。所以進行更改是一件令人畏懼的任務，即使是對那些最初開發了這個應用程序的開發人員和/或數據庫管理員。注釋你的代碼真的是一個快速並且不痛苦的過程，對於未來的開發人員以安全和省時的方式理解和修改代碼來說，這是至關重要的。
7、當然，我會測試的……
很少開發人員和數據庫管理員會喜歡簡單的測試，他們也不喜歡在發布代碼到產品環境之前進行嚴格的測試。並且，開發環境通常在硬件和數據量上都達不到產品環境的規模。就是說，簡單的查詢在幾百個或者甚至是幾千個記錄上都可以工作良好，但是在產品環境中就不是這樣了。對於你的查詢沒有別的更好的准備辦法了，只有在測試環境中對含有碎片的表中幾百萬條數據進行測試，以此來確保查詢會按照你的期望運行。
8、讓我用這個吧，就是這個!
輸入SELECT語句，沒有包含WHERE子句，期望中間層或者前端以比SQL Server更加有效的方式來處理得到的數據，這是個很糟糕的主意。SQL Server就是設計用來處理查詢，並且將其執行得非常高效的。將大量的數據移動只會讓被洪水包圍的系統和網絡陷入困境。一定要盡可能地過濾你的數據，避免對性能產生影響。
9、請讓我用視圖來查詢吧
視圖可以滿足你簡化復雜查詢中的代碼的需求。它們通常用來幫助有權利的用戶查詢數據庫。不幸的是，太多的好事情也會嚴重影響性能。視圖就是一個簡單的SELECT語句，視圖的SELECT語句必須在每次你輸入SELECT語句的時候再次輸入。限制視圖的使用，防止它們查詢其他視圖。或者，構建一個存儲過程來查詢數據，並且傳遞給它需要的參數來滿足應用程序或者用戶的需求。
10、不，這不是我的代碼……
我們都犯錯誤，我們最後工作的那個系統應該是從我們在當前系統中獲得的知識中獲益。所以，記錄你學到的東西，並且把它與你的團隊共享，讓集體受益。當你有機會的時候，回到先前的系統中，用你從那個項目中學到的知識改善它們。
結論
如果你在查詢中犯了以上或者其他的錯誤，承認錯誤，努力去糾正它。說起來容易做起來難，但是糾正這些問題會讓企業獲益，並且對應用程序的名聲有好處。看完了這篇文章，開始為你正在做或者以後要做的項目構建一個私人的代碼指南吧。
