我們正在使用MS-SQL和Oracle爲我們的數據庫。的SQL Server到Oracle表創建
我們使用Hibernate註解創建表，我們已經聲明列定義註釋類文件
@Column(name="UCAALSNO",nullable=false,columnDefinition="nvarchar(20)")
，這工作得很好MS-SQL。
但是，當涉及到Oracle nvarchar拋出一個異常，因爲oracle只支持nvarchar2。
如何創建註釋文件，支持的數據類型爲nvarchar兩個數據庫。
你可以使用NCHAR：
在MSSQL：
的nchar [（N）]
固定長度的Unicode字符串數據。 n定義了字符串長度，並且必須是1至4,000的值。存儲大小是n的兩倍，即 字節。當排序規則頁面使用雙字節字符時，存儲大小仍爲n個字節。根據不同的串中，存儲 大小的n個字節可以小於對於n指定的值。 nchar的同義詞是ISO ，是國家字符和國家字符。
而在Oracle：
NCHAR
NCHAR列的最大長度是2000個字節。它最多可容納 2000個字符。實際的數據是受到最大字節限制的2000 這兩個尺寸的限制必須同時在 運行時間得到滿足。
Nchar佔用一個固定的空間，所以對於非常大的表，nchar和nvarchar之間會有相當大的空間差異，所以您應該考慮這一點。
我通常有增量數據庫架構遷移腳本爲我生產的DB，我只依靠Hibernate的DDL爲我的集成測試內存數據庫（例如HSQLDB或H2）。這樣我首先選擇生產模式類型，而「columnDefinition」僅適用於測試模式，因此不存在衝突。
您可能需要閱讀this過，這無視N（VAR）CHAR（2）附加的複雜性，所以可以考慮設置一個默認的字符編碼：
鑑於這種情況，我寧願去最大化 靈活性前進的辦法，而這整個數據庫 轉換爲Unicode（AL32UTF8大概），只是使用。
儘管您現在可能會被推薦使用VARCHAR2，VARCHAR has been synonym和VARCAHR2很長一段時間。
所以引用了DBA的意見：
甲骨文9.2和8.1.7的文件說，本質上是一回事， 所以儘管甲骨文不斷鼓勵使用VARCHAR，所以 到目前爲止，他們還沒有這樣做任何改變它與VARCHAR2平價的東西。
我想說的是嘗試VARCHAR，因爲它支持大多數數據庫。