Типы данных в SQLite: классы хранения и динамическая типизация

Пять классов хранения вместо десятков типов

В SQLite любое значение хранится в одном из пяти классов хранения (storage classes):

• NULL — отсутствие значения.
• INTEGER — целое число со знаком, занимает от 1 до 8 байт в зависимости от величины.
• REAL — число с плавающей точкой по стандарту IEEE, 8 байт.
• TEXT — строка в кодировке базы (как правило, UTF-8).
• BLOB — сырые байты, сохраняются ровно в том виде, в котором вы их передали.

И всё. Никакого отдельного BOOLEAN, DATETIME, VARCHAR или DECIMAL. В других СУБД типов данных — десятки, а в SQLite их всего пять, и все остальные «типы» строятся поверх них.

CREATE TABLE samples (
    a INTEGER,
    b REAL,
    c TEXT,
    d BLOB
);

INSERT INTO samples VALUES (42, 3.14, 'привет', x'deadbeef');

SELECT a, typeof(a), b, typeof(b), c, typeof(c), d, typeof(d)
FROM samples;

typeof() показывает реальный класс хранения каждого значения. Вы увидите integer, real, text, blob. Эти четыре плюс null — всё, что вообще знает SQLite.

Динамическая типизация SQLite

А теперь то, что обычно удивляет тех, кто пришёл из Postgres или MySQL. В SQLite (без режима STRICT) тип, который вы указываете у колонки, — это скорее пожелание, чем обязательство. Настоящий тип хранится вместе с самим значением:

CREATE TABLE notes (
    id   INTEGER,
    body TEXT
);

INSERT INTO notes VALUES (1, 'настоящая заметка');
INSERT INTO notes VALUES ('два', 12345);

SELECT id, typeof(id), body, typeof(body) FROM notes;

Обе строки были приняты без вопросов. В колонке id в одной строке лежит целое число, в другой — текст; в body — наоборот, текст и число. SQLite спокойно хранит значения любого класса в любой колонке.

Это и есть динамическая типизация, и сделано так намеренно. Благодаря ей SQLite прощает многое — удобно для прототипов и быстрых скриптов. Но та же особенность означает, что опечатка в коде приложения может годами тихо записывать данные не того типа. Если такой компромисс вас не устраивает — а для большинства продакшен-схем так и должно быть — на помощь приходят таблицы STRICT. До них мы скоро доберёмся.

Аффинность типов в двух словах

Объявленный тип колонки не игнорируется — он задаёт ей аффинность (type affinity). Когда вы вставляете значение, SQLite пытается привести его к аффинности колонки, если преобразование проходит без потерь. Колонка TEXT, в которую попало число 42, сохранит его как текст '42'; колонка INTEGER, получившая строку '42', запишет её как целое 42. А вот если преобразование грозит потерей информации, исходный тип сохраняется как есть.

CREATE TABLE prices (
    label TEXT,
    cents INTEGER
);

INSERT INTO prices VALUES (42, '100');
INSERT INTO prices VALUES ('coffee', '3.5');

SELECT label, typeof(label), cents, typeof(cents) FROM prices;

Первая строка: целое 42 приведено к тексту '42', а строка '100' — к числу 100. Вторая строка: '3.5' нельзя без потерь конвертировать в INTEGER, поэтому значение осталось текстом. Про affinity будет отдельный разговор чуть позже — пока запомните главное: тип колонки всё-таки влияет на то, как хранятся данные, даже если жёстко его не навязывает.

Тип boolean в SQLite

Отдельного класса хранения BOOLEAN в SQLite попросту нет. Булевы значения хранятся как целые числа: 0 — это false, 1 — true:

CREATE TABLE tasks (
    title TEXT,
    done  BOOLEAN
);

INSERT INTO tasks VALUES ('написать документацию', TRUE);
INSERT INTO tasks VALUES ('выпустить релиз', FALSE);

SELECT title, done, typeof(done) FROM tasks
WHERE done = 1;

Ключевые слова TRUE и FALSE распознаются (начиная с SQLite 3.23) и превращаются в 1 и 0. Объявление BOOLEAN даёт колонке числовую аффинность, но не ограничивает её значениями 0/1 — без режима STRICT вы спокойно вставите туда 'maybe', и SQLite даже не пикнет.

Дата и время в SQLite

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

• TEXT в формате ISO-8601: '2026-04-23 14:30:00'.
• REAL — юлианский день.
• INTEGER — секунды Unix-эпохи.

CREATE TABLE events (
    name      TEXT,
    happened  TEXT
);

INSERT INTO events VALUES ('запуск', '2026-04-23 09:00:00');
INSERT INTO events VALUES ('демо',   datetime('now'));

SELECT name, happened, date(happened), strftime('%H:%M', happened)
FROM events;

Текст в формате ISO-8601 — самый популярный вариант: он корректно сортируется как строка, читается человеком, да и все встроенные функции (date(), time(), datetime(), strftime(), julianday()) умеют с ним работать. Выберите один формат на колонку и придерживайтесь его — смешивать разные представления в одном столбце означает нарваться на проблемы через полгода.

VARCHAR, CHAR и другие знакомые имена

SQLite принимает привычные по другим СУБД названия типов — VARCHAR(255), CHAR(10), NVARCHAR, DECIMAL(10,2), DOUBLE, FLOAT, INT, BIGINT, MEDIUMINT. Парсятся они без проблем. Просто по правилам аффинности каждое из них сводится к одному из пяти классов хранения.

CREATE TABLE users (
    id        BIGINT,
    name      VARCHAR(255),
    bio       NVARCHAR(2000),
    balance   DECIMAL(10, 2)
);

INSERT INTO users VALUES (1, 'Ada', 'изобретатель', 99.50);

SELECT typeof(id), typeof(name), typeof(bio), typeof(balance) FROM users;

VARCHAR(255) не ограничивает длину 255 символами — SQLite просто игнорирует это число. DECIMAL(10, 2) не хранит число с фиксированной точностью — колонка получает numeric affinity, а данные ложатся как INTEGER или REAL. Эти имена оставлены лишь для того, чтобы схемы, скопированные из других СУБД, не падали при запуске, — но связанных с ними ограничений в SQLite нет.

Если нужна точная арифметика для денег, храните центы (или копейки) как INTEGER. С REAL рано или поздно вылезут ошибки округления уже в третьем знаке после запятой.

NULL — это отдельный класс хранения

NULL — не просто «нет значения», а полноценное значение со своим классом хранения, который возвращает typeof():

CREATE TABLE optional (
    a INTEGER,
    b TEXT
);

INSERT INTO optional (a) VALUES (5);

SELECT a, typeof(a), b, typeof(b) FROM optional;

b показывается как null. Это важный момент: NULL не равен ничему — даже другому NULL. Условие b = NULL никогда не истинно, нужно писать b IS NULL. Подробнее об этом — в разделе про операторы и NULL, но начинается всё именно здесь, с класса хранения.

Хранение байтов в типе BLOB

Тип данных BLOB хранит сырые байты как есть — удобно для небольших картинок, хэшей, закодированных данных, в общем, для всего, что не является текстом или числом:

CREATE TABLE files (
    name  TEXT,
    data  BLOB
);

INSERT INTO files VALUES ('подпись', x'89504e470d0a1a0a');

SELECT name, length(data), hex(data), typeof(data) FROM files;

Литерал x'...' позволяет записывать блобы в SQL в шестнадцатеричном виде; из кода приложения обычно удобнее передавать массив байт через параметр. length() для блоба возвращает количество байт, а не символов.

Практический момент: SQLite без проблем хранит большие блобы, но тянуть 50-мегабайтный блоб через каждый запрос, который трогает строку, — медленно. Для больших файлов лучше держать сам файл на диске, а в базе хранить путь к нему.

Что стоит запомнить

• Пять классов хранения — NULL, INTEGER, REAL, TEXT, BLOB — покрывают всё.
• Булевы значения — это целые числа; даты можно хранить как текст, как REAL или как INTEGER (на ваш выбор).
• Объявленные типы колонок — это подсказки, а не жёсткие контракты (если только вы не используете STRICT-таблицы).
• VARCHAR(255) и его собратья парсятся без ошибок, но длину и точность, которые они подразумевают в других СУБД, SQLite не контролирует.
• typeof(value) — ваш лучший друг, когда непонятно, что на самом деле лежит в колонке.

Дальше: type affinity

То «подсказочное» поведение, которое мы здесь упомянули мимоходом, на самом деле описано чёткими правилами — пять классов affinity, выводимых из имени объявленного типа и применяемых при каждой вставке. Об этом — следующая страница, и именно там ключ к тому, чтобы заранее понимать, что SQLite сделает с вашими значениями.