SQL SERVER 空格的坑”以及PostgreSQL類似的坑如何避開

本篇文章為大家展示了SQL SERVER 空格的坑”以及PostgreSQL類似的坑如何避開，內(nèi)容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細(xì)介紹希望你能有所收獲。

雖然公司在大力的往開源的數(shù)據(jù)庫上轉(zhuǎn)移，但傳統(tǒng)數(shù)據(jù)庫的使用在一段時間還是會存在的，最近開發(fā)的親們報出一個怪異的現(xiàn)象，就是外部傳進(jìn)來得字符用在末尾帶有 \u0001 (在SQL SERVER  里面這又特殊的含義可以理解為char(1))，存儲進(jìn) nvarchar 字符類型后會帶有一個空格(其實(shí)存進(jìn)char也一樣)，而這樣的數(shù)據(jù)在某些特殊的規(guī)則引擎或決策引擎中就會因?yàn)檫@多的一個空格而報錯，而你去查的時候，他又不帶空格。

大家可以注意下圖，如果用len（）SQL SERVER 的傳統(tǒng)函數(shù)來查看末尾帶有空格和不帶有空格的 nvarchar 或 varchar 的變量，得到的長度是一樣的，要通過datalenght  來查看才能看到數(shù)據(jù)之間的不同，但大部分開發(fā)查看字符長度，都是使用 SQL SERVER len（） 并會得到一個錯誤結(jié)果。

而產(chǎn)生這個問題的主要原因是 SQL SERVER 如何比較字符的SQL SERVER 是遵循 ANSI/ISO SQL-92 規(guī)范來進(jìn)行字符的比較。使得在字符處理中SQL 認(rèn)為 字符串末尾帶空格和 不帶空格的對比 在大多數(shù)的比較中是相等的。

如果還不清晰，我們下面在做一個更直白的比較

OK  說到這里，上邊帶有末尾空格和不帶有空格的字符串在處理中很多情況是一樣的，實(shí)際上是不一樣的。另外想 trim的同學(xué) 也可以省省心了，照樣還是不一樣。

反過來我們比對一下 POSTGRESQL ，主要的原因是有2 

1 作為傳統(tǒng)企業(yè)，或金融企業(yè)，POSTGRESQL 在收費(fèi)到開源數(shù)據(jù)庫轉(zhuǎn)換中，會節(jié)省大量的人力物力（尤其對開發(fā)來說）

2 PG 火 （言簡意賅）

PG 中是沒有 NVARCHAR 這樣的類型的，我們使用 VARCHAR (在SQL SERVER 中VARCHAR 也有類似上面的毛病) 和 PG的 text 類型，測試是在PG admin tools 上進(jìn)行的，也是通過插入帶有空格，和不帶空格的數(shù)據(jù)來進(jìn)測試

插入兩條數(shù)據(jù) id 為 2的是帶有空格的

通過上圖的比較和證明，PG可以清晰的在查詢中分辨那個值里面包含空格，那些不是， PostgreSQL 版本 11 的這兩種字符類型，是沒有類似 SQL SREVER 那樣的'坑'

這里如果我們使用PG 中的 char類型，也會出現(xiàn)和SQL SERVER 類似的情況，所以在使用PG 的過程中，如果可以還是盡量使用  varchar 類型 或 text 類型

結(jié)論 SQL SERVER 的空格的坑是實(shí)實(shí)在在的存在，如果要避開這個坑，光在數(shù)據(jù)庫層面來搞，還是比較麻煩，并行在使用SQL SERVER 的 rtrim 函數(shù)去掉右空格也以失敗告終，而POSTGRESQL varchar   text 天然的屏蔽了這個問題，對于這類問題數(shù)據(jù)庫本身就可以解決。從另一個側(cè)面，也說明PG建表的字符字段，您還是盡量不要選擇 CHAR 類型。

上述內(nèi)容就是SQL SERVER 空格的坑”以及PostgreSQL類似的坑如何避開，你們學(xué)到知識或技能了嗎？如果還想學(xué)到更多技能或者豐富自己的知識儲備，歡迎關(guān)注億速云行業(yè)資訊頻道。