Тип данных Oracle: должен ли я использовать VARCHAR2 или CHAR

должен ли я использовать VARCHAR2 или CHAR в качестве типа данных в Oracle?

Мне было предложено использовать CHAR для этих новых таблиц, которые мне нужны, но я обеспокоен тем, что эти новые таблицы будут использоваться для заполнения существующих таблиц, которые используют тип данных VARCHAR2. Я обеспокоен дополнительными пространствами, размещенными в полях VARCHAR2, и проблемами сравнения. Я знаю, что есть способы сравнить их с помощью обрезки или преобразования, но я боюсь, что это сделает мой код грязным и детская коляска.

каковы ваши мнения?

7
oracle plsql

5 ответов

меня беспокоят дополнительные пробелы, размещаемые в полях VARCHAR2 и с проблемами сравнения. Я знаю, что есть способы сравнить их с помощью обрезки или преобразования, но я боюсь, что это сделает мой код грязным и багги.

на самом деле все наоборот. Использование CHAR заставит ваши строки быть фиксированной длиной, заполняя их пробелами, если они слишком короткие. Поэтому при сравнении символов с регулярными строками в любом приложении, использующем данные, это приложение нужно было бы добавлять обрезку каждый раз. Другими словами, VARCHAR2-это выбор, который, естественно, приводит к более чистому коду.

В общем, вы должны всегда используйте VARCHAR2, если у вас нет очень конкретной причины, почему вы хотите столбец CHAR.

Если вы беспокоитесь о строках, которые имеют дополнительное пространство в передней или в конце, то есть несколько вариантов которые приходят на ум:

  • убедитесь, что любой процесс делает вставки делает обрезку на них перед вставкой.
  • добавьте контрольное ограничение на столбец, которое гарантирует, что string = trim (строка).
  • добавьте триггер уровня строки перед вставкой, который выполняет обрезку строк по мере их вставки.
  • убедитесь, что вы делаете обрезку строк при каждом запросе таблицы
9

читать:

цитата из статьи AskTom:

тот факт, что CHAR/NCHAR на самом деле не более чем VARCHAR2 / nvarchar2 в маскировке заставляет меня думать, что есть на самом деле только два типа символьных строк, а именно VARCHAR2 и NVARCHAR2. Я нигде не нашел a использование для типа CHAR в любое приложение. Поскольку тип CHAR всегда пустые колодки в результате строка до фиксированной ширины, мы быстро обнаруживаем, что она потребляет максимальное хранение как в сегменте таблицы, так и в любых сегментах индекса. Что было бы достаточно плохо, но есть еще одна важная причина, чтобы избежать Типы CHAR/NCHAR: они создают путаницу в приложениях, которые должны получить эту информацию (многие не могут "найти" свои данные после сохранения он.) Причина этого связана с правилами символьной строки сравнение и строгость, с которой они выполняются.

4

CHAR имеет интересную семантику сравнения. Если вы используете только VARCHAR2, вам не нужно изучать семантику CHAR. Честно говоря, я думаю, что если бы у меня было поле с известной фиксированной длиной, я бы все равно определил его как VARCHAR2 и использовал контрольное ограничение для обеспечения его фиксированной длины, вместо изучения семантики сравнения символов.

некоторые будут утверждать, что символы более эффективны для данных фиксированной длины, потому что длина не должна храниться, но это неверно на Oracle.

3

Я бы предложил вам придерживаться VARCHAR2.

вы должны использовать CHAR, когда данные имеют известную фиксированную длину.

0

выбрать VARCHAR2(size) над CHAR(size), так как это более пространство и время эффективно:

удивительно или нет, CHAR(size) позволяет присваивать строки с длиной len короче size. В этом случае ORACLE добавляет size-len пробелы в строке для типов данных CHAR и VARCHAR и магазинах size символы. The VARCHAR2 тип данных поставляется без заполнения, только символы.

CREATE TABLE Demo(col1 CHAR(4), col2 VARCHAR2(4));
INSERT INTO Demo (col1, col2) VALUES ('c', 'v');

в результате

col1='c ' (проложенный с 3 конечными пробелами, так как size of col1 is 4 и длиной 'c' только 1). col1='c' оценивает FALSE, только TRIM(col1)='c' оценивает TRUE,

, тогда как

col2='v' оценивает TRUE безTRIM(), делая сравнение более эффективным.

кроме того, сравнение между двумя VARCHAR2 ценностях не получится быстро, если их длины отличаются (независимо от их size). В этом случае никакие символьные сравнения не являются требуемый. С CHAR и все же size проверка длины всегда терпит неудачу из-за подклада. Таким образом, каждый символ должен сравниваться до тех пор, пока не будет достигнуто первое несоответствие символов или конец строки, в зависимости от того, что произойдет первым.

так как CHAR(size) и VARCHAR2(size) Не препятствуйте присвоению значений короче size, определите ограничение длины, Если вам нужно гарантировать, что только значения с предопределенной длиной (которая должна равняться size) могут быть назначены.

0