Краткий ответ

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

Исторический контекст

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

Это различие сохранилось в стандарте SQL: объявленная длина задаёт допустимый размер значения, но семантика хранения и обработки зависит от типа и конкретной СУБД.

Постановка проблемы

Неверный выбор типа может привести к неожиданным результатам при сравнении, отображении и обмене данными. Если использовать CHAR для произвольных имён или описаний, значения могут дополняться конечными пробелами, а приложение — получать строки не в том виде, в котором они были введены.

Если использовать VARCHAR для фиксированного кода, схема хуже выражает бизнес-правило: строка формально может иметь любую длину до установленного максимума, если отдельно не добавлено ограничение. Это повышает риск появления некорректных данных.

Подробное решение

Значение типа CHAR(n) концептуально имеет фиксированную длину n. Более короткое значение дополняется конечными пробелами до этой длины; при извлечении конкретная СУБД может сохранять эти пробелы или удалять их, поэтому поведение приложения нужно проверять по документации используемой СУБД.

Значение типа VARCHAR(n) имеет переменную длину, но не может превышать n символов согласно правилам конкретной СУБД. Дополнение пробелами до максимальной длины не является его основной семантикой.

CREATE TABLE reference_codes (
    country_code CHAR(2) NOT NULL,
    currency_code CHAR(3) NOT NULL,
    description VARCHAR(200) NOT NULL
);

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

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

Если значение должно иметь ровно заданную длину независимо от типа, это правило следует дополнительно защищать ограничением CHECK или другим механизмом целостности. Одного выбора VARCHAR с максимальной длиной недостаточно для требования «ровно два символа».

Ситуация из практики

В системе международных платежей нужно хранить трёхсимвольный код валюты и комментарий к операции. Для кода рассматривались CHAR(3) и VARCHAR(3), а для комментария — CHAR(500) и VARCHAR(500).

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

Выбран вариант CHAR(3) для кода валюты и VARCHAR(500) для комментария. В результате схема явно отражает различие между кодом фиксированного формата и текстом переменной длины, а для внешних интеграций добавлены проверки допустимой длины и нормализация регистра.

Что кандидаты часто упускают

1. Одинаково ли сравниваются CHAR и VARCHAR при наличии конечных пробелов?

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

2. Гарантирует ли VARCHAR(n) ровно n символов?

Нет. Обычно n задаёт верхнюю границу, а не обязательную длину: значение может содержать меньше символов. Требование точной длины нужно выразить отдельным ограничением, например через CHECK, с учётом того, как СУБД считает длину в многобайтных кодировках.

3. Означает ли CHAR фиксированное физическое количество байтов?

Не обязательно. Число символов и число байтов могут различаться в кодировках Unicode, а физическое хранение зависит от СУБД и её формата страниц или строк. Поэтому CHAR(10) следует понимать прежде всего как тип фиксированной символьной длины, а не как обещание фиксированного количества байтов на диске.