WHERE語句中設定搜尋值的一些建議

在資料庫設計與管理中，WHERE子句無疑是大家用的最頻繁的一個子句之一。那麼大家是否真的擅長這個子句的使用呢?我看不見的的吧。筆者的下面這些建議就可以協助大家來充分使用WHERE子句的功能，發揮其強大的作用。

建議一：查詢條件中包含撇號怎麼處理?

資料庫的某些列中，可能會包含一些特殊的符號，如撇號(‘)。這對於SQLServer資料庫來說是一個特殊的符號。因為其原本是用來區分字元與變數的。如在查詢語句中，如果輸入的是字串的值，就需要利用兩個撇號引用起來。(有時候撇號大家又叫做單引號)。但是在有些情況下，特別是國外人的名字中，本身就包含著單引號。如某個產品的規格資訊為“8’尖嘴鉗(07型)/ 碳鋼/ 熱處理/ 全拋光/ 鍍鎳鐵合金/ 橙色”。在這個規格資訊中就有一個單引號。此時如果在WHERE查詢語句中需要查詢這個規格資訊，那麼這個單引號還如何處理呢?資料庫管理員如果按如下的格式來輸入查詢語句(WHERE Description like ‘8’尖嘴鉗’)，能夠查詢到所需要的結果呢?答案是否定的。因為此時資料庫系統因為這個查詢語句中有三個單引號分割符號，為此資料庫最佳化器在編譯最佳化這條語句的時候，無法識別輸入的條件陳述式的含義。

為此資料庫管理員在設計查詢語句的時候，就需要預計到這種情況，並在編寫語句的時候採取措施來避免這種錯誤。如果要在查詢條件中包含單引號的這個特殊符號也未嘗不可。在SQLServer資料庫中，如果需要尋找的資料包含一個單引號時，則可以輸入兩個單引號來標明這個單引號是文本值而非分隔字元。其實，這個單引號就好像程式開發語言中的轉移字元，能夠把系統中的一些特殊符號轉換成文本符號。不過由於逸出字元的使用或多或少會影響資料庫的執行效能，為此在查詢的時候還是要盡量避免在查詢條件陳述式中包含單引號。資料管理員在設計SQL查詢語句中，應該有意識的限制這種行為，而不是支援。只有在使用者確實有這方面需求的情況下，才能夠使用轉移字元來告訴資料庫把單引號當作字元資料來處理。

建議二：數值作為查詢條件的注意事項。

如果把數值作為查詢條件時，其不用單引號括起來，在數字中間也不會出現單引號等分隔字元。那麼照理來說數值作為查詢參數是最容易的事情了。其實不然。很多資料庫管理員可能不熟悉一些基本的規則，為此在使用數值作為查詢條件的時候，還是會遇到磕磕碰碰的事情。

如把數值作為查詢條件的話，則在數值中可以加入小數點。預設情況下，小數點位一個小黑點，如12.5。但是並不是在所有作業系統中都是以這個點好作為小數點的分隔點。如筆者一次在給客戶進行資料庫維護時，在客戶的電腦上使用sql語句來查詢記錄，就是把參數值輸入為12.5。但是怎麼執行資料庫都提示這條SQL語句有錯誤。筆者核對了好幾次，就是發現這個問題。但是在筆者自己的膝上型電腦上，把這條SQL語句一模一樣的照寫了一遍，執行起來的時候就沒有發生任何錯誤。這到底是怎麼回事呢?原來小數點的分隔字元預設情況下是採用小黑點，但是並不是所有作業系統這支援這個。小數點的分隔字元使用者可以進行自訂。如在Windows作業系統控制面便的地區設定中，可以根據使用者的使用習慣來定義小數點的分隔字元。當在書寫查詢條件的過程中如果使用到小數點的話，那麼就需要跟這個地區設定中的設定相符。如果在這個地區設定中是採用冒號來作為小數的分隔字元號的，那麼在查詢語句中也需要利用冒號來作為小數點的分隔字元。在資料庫編譯的時候，會自動把這個冒號轉換為位元據。為此，在有些教科書上，把小數點的分隔字元好定義為小黑點筆者人為這是不科學的，會對讀者產生誤導。筆者認為，應該這麼寫：如果把數值作為查詢條件的，則除了小數點分隔字元和負號之外，不能夠包含非數字字元。如果為了讓讀者更加明白的話，則在後面可以加一句注釋，這裡的小數點分隔字元預設情況下是小黑點符號，但是可以在控制面中中的地區設定對方框內進行重新定義。

另外在使用數值型資料作為查詢條件時，需要注意如果輸入的是正數，那麼無論搜尋的是整數還是實數，都可以包含小數點標記。也就是說，12.與12是等價的(這裡假設小數點分隔字元為.號)。而且在SQLServer資料庫中，還可以利用科學計數法來作為查詢條件。要知道利用科學計數法來表示非常大或者非常小的數字，非常有用。資料庫能夠支援科學計數法作為查詢條件，則對於一些小數或者大數的查詢非常的有用。

建議三：要注意邏輯值的表示方法。

在SQLServer資料庫中，邏輯值的應用也是很普遍的。如在員工資訊表中，往往把員工的性別利用邏輯值來表示。如員工如果是男性的話，則利用True來表示。如果員工是女性的話，則利用false來表示。再如如果某個員工離職了，為了後續查詢往往不會把這個員工資訊刪除，而是採用另外一種管理機制來進行管理。如會在這個員工資訊表中建立一個isactive等類似的布爾型欄位。如果這個員工資訊是有效，則其值就為True;如果這個員工資訊因為離職等原因已經實現了，則其就為Faluse。

但是資料庫管理需要注意這個邏輯資料的格式會因資料庫的不同而不同。如在SQLServer中，如果邏輯值為False的話，則在資料庫儲存為0;如果邏輯值為True的話，則其通常儲存的值為1。不過不同的資料庫這個對應的值可能不同，如有的資料庫利用-1來表示邏輯值False等等。為此在編寫SQL語句的時候，資料庫管理員需要注意這方面的差異，要防止張冠李戴的情況發生。

另外需要注意的是，在開發應用程式的時候，其往往不會利用數字0或者1來表示羅機值。如在C語言中直接以TRUE或者FALSE來表示布爾值。為此資料庫開發人員在開發應用系統的時候，需要注意這些表示方式上的差異。在必要的時候，需要通過別名等表達方式來進行相關的轉換。如使用者在產生報表時，如果利用1或者0數字來表示邏輯值的話，可能使用者並不一定看的懂。此時就需要在資料庫查詢的時候，進行一些轉換處理。如可以利用CASE語句來判斷並利用別名進行轉換。這也是資料庫設計過程中對邏輯值進行處理的最常見的方法。

建議四：當心日期資料的處理。

日期型的資料在資料庫中使最特殊也是最複雜的一類資料類型。其看起來像是字元型的資料，但是其操作起來要比資料型的字元負責的多。要掌握在WHERE語句中如果利用日期型的資料作為查詢條件，則資料庫管理員首先需要明白其日期的表示格式。因為不同類型的表示格式其所代表的含義是不同的。

首先資料庫管理員需要注意，在SQLServer與Windows作業系統的環境下，其日期格式可以在多個地方進行設定。如地區設定特定、資料庫特定、ANSI標準等三個方面。在資料庫部署的時候，最好把這三個地方的日期格式設定為一致，否則的話，在後續操作的時候會遇到很多不必要的麻煩。如地區設定處設定的日期格式與資料庫特定的日期格式不一致的話，則在利用日期型資料進行查詢的時候，很容易因為日期格式不相容而導致文法編譯錯誤。

其次需要注意的是，在SQL Server資料庫中有兩個地方可以產生SQL語句。一是在資料提供的視窗中產生SQL語句;二是直接編寫SQL語句。如果在其提供的查詢時段中產生SQL語句的話，則在日期型的欄位中輸入日期資料的話，則資料庫在產生SQL查詢語句的過程中，會自動對日期型的資料進行轉換，以符合於資料庫相容的日期格式。也就是說，在查詢時段輸入日期型資料查詢條件，一般不會出現問題。但是如果是在應用程式中直接編寫SQL語句，則此時需要注意，其輸入的日期要符合資料庫特定的格式或者ANSI標準的格式。而不是在地區設定處設定的格式。

第三，那麼查詢返回的結果會以什麼格式顯示呢?是按照地區設定特定的格式、還是資料庫特定的格式或者ANSI標準日期格式顯示呢?這裡要注意，其顯示的時候是以作業系統中地區設定處設定的日期格式來顯示。而不是資料庫中設定的日期格式來顯示。為此在同一個資料庫中，不同的用戶端其日期顯示格式就有可能不同。這主要是因為用戶端上面的地區設定中的日期格式設定不同而造成的。

1. 資料庫開發管理中的十條建議
2. 深入淺出SQL嵌套SELECT語句
3. 詳解MySQL分組查詢Group By實現原理