三大關系數據庫字段值超長的一個有趣對比

在開發中，我們可能會遇到插入字段值超長的情況，前陣子遇到這樣一個案例，結果一對比後發現一個有趣的現象，如果插入字段值超長，ORACLE、SQL Server、MySQL它們會提示那個字段值超長嗎？下面看看實驗吧：

ORACLE數據庫

SQL> create table test(id number(10), name varchar2(12));

Table created.

SQL> insert into test

  2  select 10, ‘kkkkkkkkkkkkkkkkkk‘ from dual;

select 10, ‘kkkkkkkkkkkkkkkkkk‘
 
 from dual

           *

ERROR at line 2:

ORA-12899: value too large for column "SYS"."TEST"."NAME" (actual: 18, maximum:

12)

MySQL數據庫

SQL> create table test(id number(10), name varchar2(12));

Table created.

SQL> insert into test

  2  select 10, ‘kkkkkkkkkkkkkkkkkk‘ from dual;

select 10, ‘kkkkkkkkkkkkkkkkkk‘
 
 from dual

           *

ERROR at line 2:

ORA-12899: value too large for column "SYS"."TEST"."NAME" (actual: 18, maximum:

12)

SQL SERVER數據庫

USE  AdventureWorks2014;

GO

CREATE TABLE TEST(ID int, NAME varchar(12));

INSERT INTO dbo.TEST 

SELECT 100,‘kkkkkkkkkkkkkkkkkkkkkkkkk‘

Msg 8152, Level 16, State 14, Line 6

String or binary data would be truncated.

The statement has been terminated.

如上實驗所示，ORACLE、MySQL都會提示具體字段超長的細節信息，而SQL Server就傻傻的提示“String or binary data would be truncated.” 如果你表結構字段有十幾個，那麽就一個個核對吧。 不吹不黑，其實SQL Server有蠻多不友好、甚至讓人詬病的地方。舉個例子，使用SqlBulkCopy插入數據時，遇到錯誤“數據源的 String 類型的給定值不能轉換為指定目標列的類型xxx”, 有可能是目標表字段的長度比要導入的數據長度小或者其它原因，難道準確、友好的提示具體出錯信息那麽難？還有使用SqlbulkCopy有時候提示“給定的 ColumnMapping 與源或目標中的任意列均不匹配”， 你妹啊，這不是坑爹嗎！ 這些都是一些細節地方，有時候真的細節見高低！此文權當吐槽篇！

三大關系數據庫字段值超長的一個有趣對比