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

Произвольные двоичные данные следует хранить в двоичном типе — например, BINARY, VARBINARY или BLOB, — потому что строковый тип интерпретирует содержимое как текст в некоторой кодировке. При таком хранении возможны ошибки декодирования, преобразование или потеря байтов, а сравнение и длина начинают зависеть от правил работы с текстом.

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

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

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

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

Если поместить произвольные байты в VARCHAR или CHAR, СУБД может попытаться проверить их как символы выбранной кодировки. Некорректная последовательность может вызвать ошибку, а преобразование между кодировками — изменить содержимое.

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

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

Для бинарного содержимого выбирают двоичный тип. BINARY обычно предназначен для двоичных строк фиксированной длины, VARBINARY — переменной длины, а BLOB — для больших двоичных объектов. Точные названия, ограничения размера и поведение конкретных типов зависят от СУБД.

CREATE TABLE attachments (
    attachment_id INTEGER PRIMARY KEY,
    content BLOB NOT NULL
);

В этом примере столбец content не требует выбора кодировки текста и не применяет к содержимому лингвистические правила сравнения. Это не означает отсутствия ограничений: СУБД и файловое хранилище могут иметь собственные пределы размера, а операции чтения больших объектов могут быть дороже обычного чтения строк.

Если бинарные данные нужно передавать через систему, допускающую только текст, применяют кодирование, например Base64 или шестнадцатеричное представление. Это делает данные переносимыми как текст, но увеличивает объём и требует обратного декодирования; такое представление не заменяет двоичное хранение на уровне модели данных.

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

Сервис загружает изображения и сначала сохраняет их в VARCHAR, потому что API принимает строки. На тестовых данных всё работает, но файл с байтами, недопустимыми для UTF-8, не проходит вставку, а некоторые преобразования при обмене изменяют содержимое.

Рассматривались два варианта. Хранение Base64 в строковом столбце проще для текстового API и удобно для небольших объектов, но увеличивает размер примерно на треть и создаёт дополнительную нагрузку на кодирование и декодирование. Хранение исходных байтов в BLOB экономичнее и сохраняет содержимое напрямую, но требует корректной поддержки бинарных данных в API и резервном копировании.

Был выбран BLOB в базе, а Base64 оставлен только на границе API. В результате байты файла сохраняются без текстовых преобразований, а текстовый формат используется лишь там, где он действительно необходим.

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

Гарантирует ли преобразование двоичных данных в текст сохранение всех байтов?

Нет. Гарантия появляется только при использовании согласованной кодировки и корректной процедуры декодирования. Если последовательность байтов не является допустимым текстом в выбранной кодировке, преобразование может завершиться ошибкой или привести к потере данных; поведение зависит от СУБД и конкретной операции приведения типов.
Всегда ли двоичный тип лучше строкового?

Нет. Для настоящего текста строковый тип правильнее: он позволяет применять кодировку, поиск, сортировку, ограничения длины в символах и текстовые функции. Двоичный тип выбирают не ради большей универсальности, а когда значение имеет байтовую, а не символьную семантику.
Означает ли выбор BLOB, что размер объекта не ограничен?

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