Сейчас на сайте
Сейчас на сайте 0 пользователей и 0 гостей.

Типы текстовой строки

ANSI поддерживает только один тип чтобы представлять текст. Это - тип CHAR. Любое поле такого типа должно иметь определенную длину. Если строка вставлена в поле меньше чем длина поля, она дополяняется пробелами; строка не может быть длиннее чем длина поля.

Хотя и достаточно удобное, это определение все же имеет некоторые ограничения для пользователя. Например, символьные поля должны иметь одинаковую длину, чтобы можно было выполнить команду UNION. Большинство реализаций, поддерживают строки переменной длины для типов данных VARCHAR и LONG VARCHAR( или просто LONG). В то врем как поле типа CHAR всегда может распределить память для максимального числа символов которое может сохраняться в поле, поле VARCHAR при любом количестве символов, может распределить только определенное количество памяти чтобы сохранить фактическое содержание поля, хотя SQL может установить снаружи, некоторое дополянительное пространство памяти чтобы следить за текущей длиной поля. Поле VARCHAR может быть любой длины, включая реализационно-определяемый максимум. Этот максимум может меняться от 254 до 2048 символов для VARCHAR, и до 16000 символов для LONG. LONG обычно используется для текста пояснительного характера или для данных, которые не могут легко сжиматься в простые значения полей; VARCHAR может использоваться для любой текстовой строки, чья длина может меняться. Между прочим, не всегда хорошо использовать VARCHAR вместо CHAR. Извлечение и модифицирование полей VARCHAR - более сложный, и следовательно более медленный процесс, чем извлечение и модифицирование полей CHAR. Кроме того, некоторое количество памяти VARCHAR, остается всегда неиспользованной (в резерве) для гарантии вмещения всей длины строки. Вы должны просчитывать, насколько значения полей могут меняться по длине, а также, способны ли они к объединению с другими полями, перед тем как решить, использовать CHAR или VARCHAR. Часто, тип LONG используется для сохранения двоичных данных. Естественно, что Использование размера такого "неуклюжего" поля будет ограничивать оперативность SQL. Проконсультируйтесь с вашим руководством.