loading..
Русский    English
07:18
листать

CHAR и VARCHAR стр. 2

Посмотрим теперь, как обстоят дела с определением данных. Ниже приведен тестовый скрипт.

  1. CREATE TABLE Test_char( chr CHAR, vchr VARCHAR );

  1. DELETE FROM Test_char;

  1. INSERT INTO Test_char
  2. VALUES ('1','11111111112222222222333333333344444444445555555555');
  3.  
  4. INSERT INTO Test_char
  5. VALUES ('11111111112222222222333333333344444444445555555555', '1');
  6.  
  7. INSERT INTO Test_char
  8. VALUES ('2',CAST('111111111122222222223333333333' AS VARCHAR));
  9.  
  10. INSERT INTO Test_char
  11. VALUES (CAST('111111111122222222223333333333' AS CHAR), '2');
  12.  
  13. INSERT INTO Test_char
  14. VALUES ('3', '3');

  1. SELECT * FROM Test_char;

SQL Server 2008

chr vchr
3 3

Итак, будет вставлена только одна строка, содержащая по одному символу для каждого из столбцов. При вставке остальных строк получаем сообщение об ошибке:

String or binary data would be truncated. The statement has been terminated.

которое означает, что следует уменьшить размер строки.

Хотя здесь выдержано соответствие стандарту, мне кажется, что есть некое противоречие в том, что не работает явное приведение к типу столбца таблицы:

  1. INSERT INTO Test_char
  2. VALUES (CAST('111111111122222222223333333333' AS CHAR), '2');

PostgreSQL 8.3

chr vchr
1 11111111112222222222333333333344444444445555555555
2 111111111122222222223333333333
1 2
3 3

Можно отметить последовательность в поведении: VARCHAR имеет произвольный размер; вторая строка не была вставлена из-за ошибки превышения размера (ERROR: value too long for type character(1)); явное преобразование значения к типу столбца таблицы работает, отсекая лишние символы справа.

MySQL 5.0

Не поддерживается тип VARCHAR без указания размера строки. CHAR соответствует CHAR(1) – по стандарту. Поскольку явное преобразование к CHAR оставляет длину строки без изменения, то в таблицу, определенную как

  1. CREATE TABLE Test_char( chr CHAR, vchr VARCHAR(1) );
в итоге, как и в SQL Server, добавится единственная строка:

chr vchr
3 3

Выводы. По моему скромному мнению, ни одна из упомянутых СУБД не отвечает стандартному поведению в тех случаях, когда размер типа не указывается. Наиболее последовательной в «особенностях реализации» является, на мой взгляд, PostgreSQL. В целях переносимости кода я бы рекомендовал всегда явно указывать размер.

Bookmark and Share
Страницы: 1 2
Тэги:
ALL AND AUTO_INCREMENT AVG battles CASE CAST CHAR CHARINDEX CHECK classes COALESCE CONSTRAINT Convert COUNT CROSS APPLY CTE DATEADD DATEDIFF DATENAME DATEPART DATETIME DDL DEFAULT DELETE DISTINCT DML EXCEPT EXISTS EXTRACT FOREIGN KEY FROM FULL JOIN GROUP BY Guadalcanal HAVING IDENTITY IN INNER JOIN insert INTERSECT IS NOT NULL ISNULL laptop LEFT LEFT OUTER JOIN LEN maker MAX MIN Больше тэгов
Учебник обновлялся
несколько дней назад
©SQL-EX,2008 [Развитие] [Связь] [О проекте] [Ссылки] [Team]
Перепечатка материалов сайта возможна только с разрешения автора.
Rambler's Top100