Начался учебный год — у меня ещё нет пар, но в преддверии занятий делюсь полезной заметкой по БД. Часто вижу, как «на всякий случай» выбирают типы побольше — в итоге едим место, замедляем индексы и ловим баги.

❌ Антипаттерны, которые встречаю:
- VARCHAR(255) «для всего подряд», даже если код фиксированной длины (например, 10 символов).
- TEXT для email-адресов.
- BIGINT для счётчика, где максимум — тысяча записей.
- FLOAT для денег (теряется точность).

✅ Как делаю сам:
- Строки — по задаче: VARCHAR(254)`/`VARCHAR(320) для email (под стандарты), CHAR(2) для кода страны.
- Деньги — только NUMERIC(10,2) / DECIMAL(10,2) или целые «копейки/центы» в INT`/`BIGINT.
- Булево — BOOLEAN, а не INT.
- Даты/время — DATE / TIMESTAMP, не строка.
- Автонумерация — INT по умолчанию; BIGINT — только если реально ждёте > 2 млрд строк.

📌 Пример
-- Плохо
price FLOAT;

-- Хорошо
price NUMERIC(10,2);

⚡️ Итог: грамотный выбор типов = меньше места, быстрее запросы, меньше багов.

#БД #SQL #PostgreSQL #Оптимизация #Backend #DataEngineering

PostgreSQL 18 уже почти на подходе, и одна из самых приятных новинок для разработчиков — нативная поддержка UUIDv7.

Если раньше gen_random_uuid() выдавал только UUIDv4 (UUIDv4 генерируются случайно, поэтому новые записи вставляются в разные места B-tree индекса. Это вызывает фрагментацию, рост размера индекса и замедление операций), то теперь у нас появляется функция uuidv7(). Она генерирует идентификаторы, упорядоченные по времени, что решает старую боль с раздутием B-tree индексов (новые ключи ложатся в «хвост» индекса, как автоинкремент, и поэтому работают быстрее).

CREATE TABLE test (
    id uuid DEFAULT uuidv7() PRIMARY KEY,
    name text
);

INSERT INTO test (name) VALUES ('foo'), ('bar');
SELECT uuid_extract_timestamp(id), name FROM test ORDER BY id;

Теперь IDшники не только уникальны, но и красиво сортируются по времени создания 👌
Для распределённых систем и масштабных БД — прямо must-have.

#postgresql #uuid #uuidv7 #базыданных