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

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

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

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

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

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

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

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

1 作為傳統企業，或金融企業，POSTGRESQL 在收費到開源數據庫轉換中，會節省大量的人力物力（尤其對開發來說）

2 PG 火 （言簡意賅）

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

插入兩條數據 id 為 2的是帶有空格的

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

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

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

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