SQL Server常見(jiàn)的需要避免的查詢(xún)?cè)O(shè)計(jì)錯(cuò)誤：
1、如果你在構(gòu)建數(shù)據(jù)模型的時(shí)候沒(méi)有考慮到數(shù)據(jù)的訪問(wèn)方式，將會(huì)導(dǎo)致難以處理的查詢(xún)。你可能會(huì)用到根本不必要的JOIN增加代碼，損害性能。
假如你要糾正這個(gè)問(wèn)題，可以考慮一下需要訪問(wèn)數(shù)據(jù)的查詢(xún)。如果查詢(xún)?cè)谶@個(gè)處理階段不是很清晰，那么將來(lái)在寫(xiě)代碼的時(shí)候就會(huì)更困難。很有可能是數(shù)據(jù)庫(kù)設(shè)計(jì)過(guò)于復(fù)雜，可以通過(guò)簡(jiǎn)化來(lái)改善查詢(xún)的性能。
與此相關(guān)，如果你是個(gè)喜歡直觀的人，那么就打印出數(shù)據(jù)模型，或者在你選擇數(shù)據(jù)建模工具的時(shí)候查看一下在線的模型。這可以改善你的代碼時(shí)間和精確性。
2、傳統(tǒng)的說(shuō)法是，對(duì)所有的數(shù)據(jù)庫(kù)訪問(wèn)都使用基于集合的邏輯。一般來(lái)說(shuō)，我同意這是的經(jīng)驗(yàn)之一。當(dāng)基于集合的邏輯是正確的選擇的時(shí)候，卻使用了指針，可能會(huì)對(duì)性能產(chǎn)生很大的損害。SQL Server的設(shè)計(jì)是使用基于集合的邏輯，并且在大多數(shù)處理中應(yīng)該使用它。
事分兩面，另一面就是指針的例子。在這種情況下，指針邏輯勝過(guò)基于集合的邏輯。從這個(gè)信息引申出來(lái)的結(jié)論就是，判斷你要執(zhí)行的處理的類(lèi)型，選擇最適合需要的技巧。
3、SQL Server 2005為你的查詢(xún)提供了一整套新的機(jī)會(huì)。所以使用老的辦法可能仍然會(huì)起作用，但是也是時(shí)候去考慮一下最新的選擇了。TRY…CATCH錯(cuò)誤處理方法是你最先應(yīng)該使用在代碼中的技巧之一。此外還要考慮的是對(duì)層次進(jìn)行處理的時(shí)候，可以用到通用表壓縮;最后一項(xiàng)考慮是擴(kuò)展關(guān)系型數(shù)據(jù)庫(kù)引擎的功能:通用語(yǔ)言運(yùn)行時(shí)(CLR)。這三項(xiàng)技術(shù)都在極大程度上改變了你使用SQL Server工作的方式，而它們只是冰山一角。
4、檢查你的代碼，然后安排一個(gè)時(shí)間進(jìn)行同樣的查看，這是在部署代碼之前必須要做的事情。檢查你的代碼，明確查詢(xún)計(jì)劃，是確保使用了合適的索引，并且查詢(xún)會(huì)像你期望的那樣運(yùn)行的重要保障。
5、輸入SELECT *語(yǔ)句，想著表永遠(yuǎn)不會(huì)改變，這是一個(gè)經(jīng)典的查詢(xún)?cè)O(shè)計(jì)錯(cuò)誤。即使在最簡(jiǎn)單的解決方案中，表的改變也是不可避免的，你需要查看代碼確保沒(méi)有包含一個(gè)額外的字段?；蛘?，更糟糕的是，你必須等待應(yīng)用程序崩潰，然后修正這些問(wèn)題。的實(shí)踐方案只是在你的查詢(xún)中包含進(jìn)來(lái)你需要的那些字段，然后必要的話(huà)就修改它們。不要把你的時(shí)間浪費(fèi)在四處冒煙的模式中徹查代碼。
6、不幸的是，我見(jiàn)過(guò)的大多數(shù)代碼都很少或者根本沒(méi)有注釋。所以進(jìn)行更改是一件令人畏懼的任務(wù)，即使是對(duì)那些最初開(kāi)發(fā)了這個(gè)應(yīng)用程序的開(kāi)發(fā)人員和/或數(shù)據(jù)庫(kù)管理員。注釋你的代碼真的是一個(gè)快速并且不痛苦的過(guò)程，對(duì)于未來(lái)的開(kāi)發(fā)人員以安全和省時(shí)的方式理解和修改代碼來(lái)說(shuō)，這是至關(guān)重要的。
7、很少有開(kāi)發(fā)人員和數(shù)據(jù)庫(kù)管理員會(huì)喜歡簡(jiǎn)單的測(cè)試，他們也不喜歡在發(fā)布代碼到產(chǎn)品環(huán)境之前進(jìn)行嚴(yán)格的測(cè)試。并且，開(kāi)發(fā)環(huán)境通常在硬件和數(shù)據(jù)量上都達(dá)不到產(chǎn)品環(huán)境的規(guī)模。就是說(shuō)，簡(jiǎn)單的查詢(xún)?cè)趲装賯€(gè)或者甚至是幾千個(gè)記錄上都可以工作良好，但是在產(chǎn)品環(huán)境中就不是這樣了。對(duì)于你的查詢(xún)沒(méi)有別的更好的準(zhǔn)備辦法了，只有在測(cè)試環(huán)境中對(duì)含有碎片的表中幾百萬(wàn)條數(shù)據(jù)進(jìn)行測(cè)試，以此來(lái)確保查詢(xún)會(huì)按照你的期望運(yùn)行。
8、輸入SELECT語(yǔ)句，沒(méi)有包含WHERE子句，期望中間層或者前端以比SQL Server更加有效的方式來(lái)處理得到的數(shù)據(jù)，這是個(gè)很糟糕的主意。SQL Server就是設(shè)計(jì)用來(lái)處理查詢(xún)，并且將其執(zhí)行得非常高效的。將大量的數(shù)據(jù)移動(dòng)只會(huì)讓被洪水包圍的系統(tǒng)和網(wǎng)絡(luò)陷入困境。一定要盡可能地過(guò)濾你的數(shù)據(jù)，避免對(duì)性能產(chǎn)生影響。
9、視圖可以滿(mǎn)足你簡(jiǎn)化復(fù)雜查詢(xún)中的代碼的需求。它們通常用來(lái)幫助有權(quán)利的用戶(hù)查詢(xún)數(shù)據(jù)庫(kù)。不幸的是，太多的好事情也會(huì)嚴(yán)重影響性能。視圖就是一個(gè)簡(jiǎn)單的SELECT語(yǔ)句，視圖的SELECT語(yǔ)句必須在每次你輸入SELECT語(yǔ)句的時(shí)候再次輸入。限制視圖的使用，防止它們查詢(xún)其他視圖。或者，構(gòu)建一個(gè)存儲(chǔ)過(guò)程來(lái)查詢(xún)數(shù)據(jù)，并且傳遞給它需要的參數(shù)來(lái)滿(mǎn)足應(yīng)用程序或者用戶(hù)的需求。
1、如果你在構(gòu)建數(shù)據(jù)模型的時(shí)候沒(méi)有考慮到數(shù)據(jù)的訪問(wèn)方式，將會(huì)導(dǎo)致難以處理的查詢(xún)。你可能會(huì)用到根本不必要的JOIN增加代碼，損害性能。
假如你要糾正這個(gè)問(wèn)題，可以考慮一下需要訪問(wèn)數(shù)據(jù)的查詢(xún)。如果查詢(xún)?cè)谶@個(gè)處理階段不是很清晰，那么將來(lái)在寫(xiě)代碼的時(shí)候就會(huì)更困難。很有可能是數(shù)據(jù)庫(kù)設(shè)計(jì)過(guò)于復(fù)雜，可以通過(guò)簡(jiǎn)化來(lái)改善查詢(xún)的性能。
與此相關(guān)，如果你是個(gè)喜歡直觀的人，那么就打印出數(shù)據(jù)模型，或者在你選擇數(shù)據(jù)建模工具的時(shí)候查看一下在線的模型。這可以改善你的代碼時(shí)間和精確性。
2、傳統(tǒng)的說(shuō)法是，對(duì)所有的數(shù)據(jù)庫(kù)訪問(wèn)都使用基于集合的邏輯。一般來(lái)說(shuō)，我同意這是的經(jīng)驗(yàn)之一。當(dāng)基于集合的邏輯是正確的選擇的時(shí)候，卻使用了指針，可能會(huì)對(duì)性能產(chǎn)生很大的損害。SQL Server的設(shè)計(jì)是使用基于集合的邏輯，并且在大多數(shù)處理中應(yīng)該使用它。
事分兩面，另一面就是指針的例子。在這種情況下，指針邏輯勝過(guò)基于集合的邏輯。從這個(gè)信息引申出來(lái)的結(jié)論就是，判斷你要執(zhí)行的處理的類(lèi)型，選擇最適合需要的技巧。
3、SQL Server 2005為你的查詢(xún)提供了一整套新的機(jī)會(huì)。所以使用老的辦法可能仍然會(huì)起作用，但是也是時(shí)候去考慮一下最新的選擇了。TRY…CATCH錯(cuò)誤處理方法是你最先應(yīng)該使用在代碼中的技巧之一。此外還要考慮的是對(duì)層次進(jìn)行處理的時(shí)候，可以用到通用表壓縮;最后一項(xiàng)考慮是擴(kuò)展關(guān)系型數(shù)據(jù)庫(kù)引擎的功能:通用語(yǔ)言運(yùn)行時(shí)(CLR)。這三項(xiàng)技術(shù)都在極大程度上改變了你使用SQL Server工作的方式，而它們只是冰山一角。
4、檢查你的代碼，然后安排一個(gè)時(shí)間進(jìn)行同樣的查看，這是在部署代碼之前必須要做的事情。檢查你的代碼，明確查詢(xún)計(jì)劃，是確保使用了合適的索引，并且查詢(xún)會(huì)像你期望的那樣運(yùn)行的重要保障。
5、輸入SELECT *語(yǔ)句，想著表永遠(yuǎn)不會(huì)改變，這是一個(gè)經(jīng)典的查詢(xún)?cè)O(shè)計(jì)錯(cuò)誤。即使在最簡(jiǎn)單的解決方案中，表的改變也是不可避免的，你需要查看代碼確保沒(méi)有包含一個(gè)額外的字段?；蛘?，更糟糕的是，你必須等待應(yīng)用程序崩潰，然后修正這些問(wèn)題。的實(shí)踐方案只是在你的查詢(xún)中包含進(jìn)來(lái)你需要的那些字段，然后必要的話(huà)就修改它們。不要把你的時(shí)間浪費(fèi)在四處冒煙的模式中徹查代碼。
6、不幸的是，我見(jiàn)過(guò)的大多數(shù)代碼都很少或者根本沒(méi)有注釋。所以進(jìn)行更改是一件令人畏懼的任務(wù)，即使是對(duì)那些最初開(kāi)發(fā)了這個(gè)應(yīng)用程序的開(kāi)發(fā)人員和/或數(shù)據(jù)庫(kù)管理員。注釋你的代碼真的是一個(gè)快速并且不痛苦的過(guò)程，對(duì)于未來(lái)的開(kāi)發(fā)人員以安全和省時(shí)的方式理解和修改代碼來(lái)說(shuō)，這是至關(guān)重要的。
7、很少有開(kāi)發(fā)人員和數(shù)據(jù)庫(kù)管理員會(huì)喜歡簡(jiǎn)單的測(cè)試，他們也不喜歡在發(fā)布代碼到產(chǎn)品環(huán)境之前進(jìn)行嚴(yán)格的測(cè)試。并且，開(kāi)發(fā)環(huán)境通常在硬件和數(shù)據(jù)量上都達(dá)不到產(chǎn)品環(huán)境的規(guī)模。就是說(shuō)，簡(jiǎn)單的查詢(xún)?cè)趲装賯€(gè)或者甚至是幾千個(gè)記錄上都可以工作良好，但是在產(chǎn)品環(huán)境中就不是這樣了。對(duì)于你的查詢(xún)沒(méi)有別的更好的準(zhǔn)備辦法了，只有在測(cè)試環(huán)境中對(duì)含有碎片的表中幾百萬(wàn)條數(shù)據(jù)進(jìn)行測(cè)試，以此來(lái)確保查詢(xún)會(huì)按照你的期望運(yùn)行。
8、輸入SELECT語(yǔ)句，沒(méi)有包含WHERE子句，期望中間層或者前端以比SQL Server更加有效的方式來(lái)處理得到的數(shù)據(jù)，這是個(gè)很糟糕的主意。SQL Server就是設(shè)計(jì)用來(lái)處理查詢(xún)，并且將其執(zhí)行得非常高效的。將大量的數(shù)據(jù)移動(dòng)只會(huì)讓被洪水包圍的系統(tǒng)和網(wǎng)絡(luò)陷入困境。一定要盡可能地過(guò)濾你的數(shù)據(jù)，避免對(duì)性能產(chǎn)生影響。
9、視圖可以滿(mǎn)足你簡(jiǎn)化復(fù)雜查詢(xún)中的代碼的需求。它們通常用來(lái)幫助有權(quán)利的用戶(hù)查詢(xún)數(shù)據(jù)庫(kù)。不幸的是，太多的好事情也會(huì)嚴(yán)重影響性能。視圖就是一個(gè)簡(jiǎn)單的SELECT語(yǔ)句，視圖的SELECT語(yǔ)句必須在每次你輸入SELECT語(yǔ)句的時(shí)候再次輸入。限制視圖的使用，防止它們查詢(xún)其他視圖。或者，構(gòu)建一個(gè)存儲(chǔ)過(guò)程來(lái)查詢(xún)數(shù)據(jù)，并且傳遞給它需要的參數(shù)來(lái)滿(mǎn)足應(yīng)用程序或者用戶(hù)的需求。