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

Question

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

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

Каково ваше мнение?

Answer 1

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

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

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

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

• Перед вставкой убедитесь, что любой процесс, выполняющий вставки, обрезает их.
• Добавьтепроверьте ограничение для столбца, который гарантирует, что string = trim (string).
• Добавьте триггер на уровне строки перед вставкой, который выполняет обрезку строк при их вставке.
• Убедитесь, чтоВы выполняете обрезку строк всякий раз, когда запрашиваете таблицу

Answer 2

Чтение:

• CHAR и VARCHAR2 Семантика (документация)
• Следует ли использовать char или varchar2 (AskTom)

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

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

Answer 3

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

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

Answer 4

Выберите VARCHAR2(size) вместо CHAR(size), так как это экономит место и время:

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

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

В результате

col1='c ' (дополняется 3 пробелами, поскольку size из col1 равно 4, а длина 'c' равна только 1). col1='c' оценивает FALSE, только TRIM(col1)='c' оценивает TRUE,

тогда

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

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

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

Answer 5

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

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