Postgresql character varying和character的區(qū)別

SQL 標準

SQL 定義了兩種基本的字符類型：character varying(n) 和 character(n) ，這里的 n 是一個正整數。兩種類型都可以存儲最多 n 個字符的字符串。

試圖存儲更長的字符串到這些類型的字段里會產生一個錯誤，除非超出長度的字符都是空白，這種情況下該字符串將被截斷為最大長度。

這個看上去有點怪異的例外是 SQL 標準要求的。如果要存儲的字符串比聲明的長度短，類型為 character 的數值將會用空白填滿；而類型為 character varying 的數值將只是存儲短些的字符串。

如果我們明確地把一個數值轉換成 character varying(n) 或 character(n) ，那么超長的數值將被截斷成 n 個字符，且不會拋出錯誤。這也是 SQL 標準的要求。

postgreSQL 字符類型

長度區(qū)別

varchar(n) 和 char(n) 分別是 character varying(n) 和 character(n) 的別名，沒有聲明長度的 character 等于 character(1) ；character varying 不帶長度使用 ，那么該類型接受任何長度的字符串。后者是 PostgreSQL 的擴展。

另外，PostgreSQL 提供 text 類型，它可以存儲任何長度的字符串。盡管text類型不是 SQL 標準，但是許多 SQL 數據庫系統(tǒng)也有它。

物理存儲

character 類型的數據，在物理上都用空格（原文: space）填充到指定長度 n 并且以這種方式存儲和顯示。不過，填充的空白在是無語意的。

在比較兩個 character 值的時候，填充的空白都會被忽略，在轉換成其它字符串類型的時候，character 值里面的空格會被刪除。請注意，在 character varying 和 text 類型的數據里，結尾的空白是有語意的。

這些類型的存儲需求是 4 字節(jié)加上實際的字符串，如果是 character 的話再加上填充的字節(jié)（上面提到的空格）。

長字符串將會自動被系統(tǒng)壓縮，因此在磁盤上的物理需求可能會更少些。長字符串也會存儲在后臺表里面，這樣它們就不會干擾對短字段的快速訪問（我的理解是：磁盤尋址路徑或者次數更少？有知道的還望指出?。。。?。不管怎樣，允許存儲的最長字符串大概是 1GB 。

允許在數據類型聲明中出現的 n 的最大值小于該最大值。更改此值不是很有用，因為使用多字節(jié)字符編碼時，字符和字節(jié)數可能會完全不同。

如果你想存儲沒有特定上限的長字符串，那么使用 text 或沒有長度聲明詞的 character varying ，而不要設定長度限制。

性能差異

這三種類型之間沒有性能差別，只不過是在使用 character 的時候增加了存儲尺寸。

雖然在某些其它的數據庫系統(tǒng)里，character(n) 有一定的性能優(yōu)勢，但在 PostgreSQL 里沒有。

在大多數情況下，應該使用 text 或 character varying 。

參考：pg 8.2.23文檔

Postgresql的character varying = bytea問題

Java開發(fā)Postgresql 數據庫兼容應用的問題，與Oracle有一些不同：

Java類型映射數據庫類型的不同，Oracle jdbc驅動程序處理Java String類型可正常映射到數據庫的Numberic（Integer），而Postgres則會出錯。

另外，則是使用hibernate時經常的錯誤: operator不存在：character varying = bytea問題，不要被這個描述誤導了，并不是sql語句中character varying = bytea類型的比較，而是當使用hibernate使用參數綁定，而參數的值為null時，hibernate或者Postgresql驅動將這個參數 映射為varbinary類型，Postgresql將varbinary認為為bytea類型

以上為個人經驗，希望能給大家一個參考，也希望大家多多支持腳本之家。

最新評論