我們的系統的的選擇框的選項是存儲在一個數據庫表中的，其中大致包含了選擇框的id以及選擇選項的數據，大致如下表。其中fieldid的類型為int，optionVal為int，optionName為varchar。

今天在做需求的時候，沒有註意相應字段的類型，直接通過java代碼就拼接了sql，大致如下。

StringBuilder sqlBuilder = new StringBuilder();
sqlBuilder.append
 
("UPDATE tablename SET")
    .append(optionFieldid)
    .append(" = ‘")
    .append(optionValue);
    .append("‘");

optionValue字符串為‘‘時他存儲在數據庫裏面的值就變成了0，原以為應該把這個字段變成‘‘，這時我才註意到這個字段的類型為int，發生了隱式類型轉換。這裏總結一下相關數據庫的隱式類型轉換，同時在接下來的開發過程中需要多加註意數據庫的類型，避免產生意想不到的結果。

oracle

oracle遵循如下的數據類型轉換規則：

• 對於insert和update操作，oracle將值轉換為受影響的的列的類型。
• 對於SELECT FROM操作，oracle會將列的值的類型轉換為目標變量的類型。
• 當操作數字類型的值的時候，oracle通常會調整精度，以適應最大的容量。在者中情況下，數字類型的操作的結果可能與上表有差異。

• 當字符串類型和數值類型做比較時，oracle會將字符串類型轉換為數值類型。

  select sysdate from dual where 1.2 = ‘1.2‘; //正確
  select sysdate from dual where 1.2 = ‘1.2a‘;//ORA-01722: 無效數字

• 使用字符串或者NUMBER類型和浮點數類型進行比較是不精確的。因為字符串和NUMBER類型使用的是decimal
  精度，而浮點數使用的是binary精度。
• 當把CLOB類型的數據轉換為向VARCHAR2這樣的類型，或者將BLOB轉換為RAW數據，如果被轉換的數據比目標類型大，那麽將會報錯。
• 在將timestamp類型轉換為date類型的時候，小數秒部分會被階段。
• 從BINARY_FLOAT轉換為BINARY_DOUBLE是精確的。
• 從BINARY_DOUBLE轉換到BINARY_FLOAT類型時，如果BINARY_ DOUBLE使用了超過BINARY_FLOAT支持的精度，那麽轉換是不精確的。

• 當字符串值和date值比較時，會將字符串值轉換為date類型。對於這種情況我們不應該依賴隱式轉換，應該使用TO_DATE進行顯示轉換，隱式轉換遵循的轉換格式如下：

  select * from nls_session_parameters  WHERE parameter=‘NLS_DATE_FORMAT‘; //DD-MON-RR

  所以在中文環境下使用如下，使用其他的格式則會報錯ORA-01861: 文字與格式字符串不匹配。

  select 1 + 1 from dual where to_date(‘2018-1-15 12:23:23‘,‘yyyy-mm-dd hh24:mi:ss‘) > ‘15-1月 -18‘;

• 當你使用sql或者函數，傳的參數不是參數接受的類型，那麽會把傳的這個參數轉換為函數接受的類型。

• 當字符串和一個非字符串類型進行比較或者算數運算時，會將字符串轉換為列一個數據的類型。當算數運算的兩邊是CHAR/VARCHAR2 和 NCHAR/NVARCHAR2，oracle將他們轉換為NUMBER。

  select ‘123‘ + ‘123.2‘ from dual; //246.2

oracle隱式類型轉換