Всем привет)) Совместно @simulative_official организуем буткемп по SQL, регистрация доступна уже сейчас, буду рад вашему участию 👩‍💻

📥 Гайд по LIMIT и OFFSET

Когда вы работаете с большими таблицами, часто не нужны все строки сразу. Например, вы хотите:

➖ показать топ-10 самых дорогих товаров,
➖ вывести последние 20 заказов,
➖ сделать постраничную навигацию в приложении.
➖ вам просто лень писать фильтры, ведь для анализа/оценки хватит n-строк таблицы. НО учтите что будет полное сканирование таблицы!

Для этого в SQL есть два оператора (точнее clauses): LIMIT и OFFSET.

📥 LIMIT — сколько строк выбрать.

LIMIT ограничивает количество строк, которое вернёт запрос.

Пример:

SELECT * 
FROM products
ORDER BY price DESC
LIMIT 5; -- берём только 5 самых дорогих товаров

Что происходит:
➖ ORDER BY price DESC — сортируем товары по убыванию цены.
➖ LIMIT 5 — берём только первые 5 строк после сортировки.

📥 Советы:
➖ Без ORDER BY LIMIT вернёт произвольные строки — на больших таблицах результат может быть сомнительным.
➖ LIMIT экономит ресурсы: не нужно считывать все данные, когда вам нужны только несколько строк.

📥 OFFSET — с какой строки начать.

OFFSET пропускает указанное количество строк перед выборкой.

Пример:

SELECT * 
FROM products
ORDER BY price DESC
LIMIT 5 OFFSET 5; -- берём строки с 6 по 10

Что происходит:
➖ Сортируем товары по цене (ORDER BY price DESC).
➖ Пропускаем первые 5 строк (OFFSET 5).
➖ Берём следующие 5 строк (LIMIT 5).

🪙 Практическое применение: пагинация

LIMIT + OFFSET идеально подходят для страниц сайта или приложения (бэк UI), но можно юзать и при подготовке отчетности, если ложиться в условия ее формирования.

-- Страница 1
SELECT * FROM orders ORDER BY order_date DESC LIMIT 20 OFFSET 0;

-- Страница 2
SELECT * FROM orders ORDER BY order_date DESC LIMIT 20 OFFSET 20;

-- Страница 3
SELECT * FROM orders ORDER BY order_date DESC LIMIT 20 OFFSET 40;

Каждый раз вы берёте новую порцию данных без лишней нагрузки на базу.

🪙 Стоит упомянуть:

Случайные строки с LIMIT.
Чтобы взять случайные строки из таблицы:

SELECT * 
FROM users
ORDER BY RANDOM() -- в разных СУБД отличается 
LIMIT 5;

LIMIT в подзапросах.
Можно использовать LIMIT для выборки топ-N в подзапросах:

SELECT *
FROM users
WHERE id IN (
    SELECT id
    FROM users
    ORDER BY created_at DESC
    LIMIT 10
);

Всегда используйте ORDER BY с LIMIT. Иначе “первые N” строки могут быть случайными.

🪙 Итог

LIMIT n — Берёт первые n строк
OFFSET m — Пропускает первые m строк
LIMIT n OFFSET m — Берёт n строк, пропустив первые m

Запомните: LIMIT — сколько строк грузить, OFFSET — с какой строки грузить.

#SQL #LIMIT #OFFSET

📱 Подписаться на канал
💻 Курс автора по SQL DDL
🌎 Мой ИТ-стартап

❗️ HAVING в SQL

Многие думают, что оператор HAVING — это просто аналог WHERE, но после GROUP BY. Это упрощение, которое может привести к путанице. Давайте разберём настоящую теорию — шаг за шагом.

Здесь нужно понимать, что SQL-запрос выполняется СУБД не в том порядке, в котором он написан человеком. Это критически важно для понимания HAVING.

❗️ Логический порядок с точки зрения исполнения СУБД (упрощённо):
1. FROM — загрузка данных из таблиц(ы)
2. WHERE — фильтрация отдельных строк
3. GROUP BY — разбиение оставшихся строк на группы
4. Вычисление агрегатных функций (COUNT, SUM, AVG и т.д.) для каждой группы
5. HAVING — фильтрация групп на основе результатов агрегации
6. SELECT — формирование выходных колонок (включая алиасы)
7. ORDER BY, LIMIT, и т.д.

⛔️ Именно потому, что агрегаты появляются только на шаге 4, их нельзя использовать в WHERE — на момент выполнения WHERE (шаг 2) групп ещё не существует!

❗️ HAVING — это условие в SQL, которое фильтрует группы строк после того, как они были объединены с помощью GROUP BY.

❗️ Что такое «группа» в реляционной алгебре?

SQL основан на реляционной алгебре. Оператор GROUP BY трансформирует отношение (таблицу) в множество групп, где каждая группа — это подмножество строк с одинаковым значением ключа группировки.

Пример:

GROUP BY department

Cоздаёт столько групп, сколько уникальных значений в колонке department. Каждая такая группа — новая логическая единица, и к ней можно применять агрегатные функции, которые сводят множество строк к одному значению (например, средняя зарплата в отделе).

❗️ Почему WHERE не может работать с агрегатами?

Потому что WHERE работает на уровне кортежей (строк), а не групп. Он отвечает на вопрос: «Оставить ли эту конкретную строку в результирующем наборе до группировки?». Агрегатные функции, напротив, не определены для одной строки — они требуют множества. Например, AVG(salary) для одной строки — это просто salary, но SQL не позволяет так делать в WHERE, чтобы избежать семантической неоднозначности.

❗️ Когда использовать HAVING?
Используй HAVING, когда твоё условие зависит от результата агрегации по группе.

❗️ Примеры:
➖ «Отделы с более чем 10 сотрудниками» — HAVING COUNT(*) > 10
➖ «Категории товаров, где общая выручка < 1000» — HAVING SUM(price * quantity) < 1000
➖ «Пользователи, сделавшие хотя бы 3 заказа» — HAVING COUNT(order_id) >= 3

❗️ Пример в коде:
Найдём отделы, где средняя зарплата больше 70 000.

SELECT department, AVG(salary) AS avg_salary
FROM employees
GROUP BY department
HAVING AVG(salary) > 70000;

Если попытаться написать это через WHERE — получим ошибку:

WHERE AVG(salary) > 70000
-- СУБД заруинила запрос

Потому что на этапе WHERE ещё нет групп, а значит — нет и средней зарплаты по отделу.

❗️ Итого
Используй WHERE, если фильтруешь по конкретным значениям (например, status = 'active').
Используй HAVING, если фильтруешь по результатам агрегации (COUNT(*) > 5, AVG(price) < 100).

#SQL #HAVING

📱 Подписаться на канал
💻 Курс автора по SQL DDL
🌎 Мой ИТ-стартап

Если вы задумывались над тем, чем же все-таки занимаются аналитики, рекомендую подписаться на канал Data Brew!

Канал ведет тот самый аналитик, который смог построить карьеру после курсов и сейчас продолжает расти профессионально.

Автор
🤗 помогает в поиске работы
😊пишет о полезных для аналитиков хардах
🎁делится реальными историями с собеседований
🤬 рассказывает о боли аналитиков
😇 скидывает аналитические мемы

Подписывайся на @data_brew

🐘 От академического проекта до лидера open-source: история PostgreSQL

Продолжим тему постов про историю SQL и СУБД, ранее мы уже разбирали:

➖ Как создатель MySQL потерял миллиарды
➖ Историю SQL: от лаборатории IBM до ядра современного ИТ

Теперь настало время одной из самых популярных промышленных СУБД — PostgreSQL

❗️ Начало, проект "Ingres"

Всё началось в 1986 году в Калифорнийском университете в Беркли. Группа исследователей под руководством профессора Майкла Стоунабрейкера уже создала реляционную СУБД Ingres — одну из первых в мире. Но им захотелось большего. Они решили пойти дальше реляционной модели и создать объектно-реляционную СУБД, которая поддерживала бы сложные типы данных, наследование и пользовательские функции. Так родился проект Post-Ingres — "после Ingres".

❗️ Рождение open-source

В 1994 году два аспиранта Андреас Энглесберг и Джонсон Ло портировали Postgres на язык C и добавили поддержку SQL. Это стало поворотным моментом. В том же году код был открыт под лицензией BSD и началась эра сообщества. В 1996 году название изменили на PostgreSQL, чтобы подчеркнуть совместимость со стандартом.

PostgreSQL — одна из самых старых open-source СУБД, которая активно развивается без корпоративного владельца. Никакой Oracle, Microsoft или Google за спиной — только сообщество энтузиастов и профессионалов.

❗️ Эволюция версий: от 6.0 до 16+

➖ 1996: Выходит PostgreSQL 6.0 — первая официальная версия с SQL.
➖ 1997: Появляется поддержка транзакций и многоверсионного контроля параллелизма (MVCC) — технологии, которая сегодня лежит в основе производительности PostgreSQL.
➖ 2005: Версия 8.0 — первая нативная сборка для Windows.
➖ 2010: Поддержка JSON (ещё до бума NoSQL!).
➖ 2012: JSONB — бинарный, индексируемый JSON. Это стало прорывом: PostgreSQL начал конкурировать с документными базами.
➖ 2018: Версия 11 — параллельное создание индексов, улучшенная масштабируемость.
➖ 2023: PostgreSQL 16 — улучшения в логической репликации, безопасность, производительность аналитических запросов.
➖ 2025: Ожидаеться выход версии 18

PostgreSQL поддерживает более 40 расширяемых типов данных, включая географические (PostGIS), полнотекстовый поиск, массивы, диапазоны, UUID, IP-адреса и даже пользовательские типы.

❗️ Почему PostgreSQL так популярен?

➖ Следует SQL-стандартам лучше, чем многие коммерческие СУБД.
➖ Можно добавлять свои типы, функции, операторы, даже языки программирования (PL/Python, PL/Perl и др.).
➖ ACID-совместимость, отказоустойчивость, репликация.
➖ Более 1000 активных контрибьюторов, регулярные релизы раз в год, никакого vendor lock-in.

Компании вроде Apple, Spotify, Reddit, Cisco и IMDb, Магнит, Яндекс, Сбер используют PostgreSQL в продакшене — иногда с тысячами серверов.

🐘 А почему слон?

➖ Идея слона как символа PostgreSQL появилась в 1997 году — её предложил участник сообщества Дэвид Янг, вдохновлённый детективом Агаты Кристи «Слоны умеют помнить».
➖ В апреле 1999 года в Санкт-Петербурге руководитель небольшой дизайн-студии Дмитрий Самерсов инициировал создание логотипа, а дизайнер Екатерина Папчинская нарисовала эскиз — знаменитого "слона в алмазе"
➖ 12 апреля 1999 года изображение под названием slonik.gif было выложено на сайт Дмитрия и отправлено в рассылку pgsql-hackers. Название мгновенно прижилось и стало легендой международного сообщества. Позже логотип стилизовался и пришел к современному варианту.

❗️ Будущее

PostgreSQL продолжает развиваться:
➖ Улучшение работы с AI/ML (через расширения вроде MADlib),
➖ Поддержка векторных встраиваний (для поиска по схожести — актуально для LLM!),
➖ Ещё более мощная логическая репликация,
➖ Оптимизация для облачных и распределённых сред.

❗️ В заключение

Постгре это не просто база данных — это живая легенда с более чем 35-летней историей, открытая для всех и созданная благодаря уму, упорству и страсти к качеству.
И всё это — благодаря университетскому проекту 1980-х, который отказался умирать.

#SQL

📱 Подписаться на канал
💻 Курс автора по SQL DDL
🌎 Мой ИТ-стартап

💡 Реляционная модель, это не просто таблицы. Это договор между людьми

Когда я только начал работать аналитиком, я думал, что база данных это просто место, где хранятся цифры. Потом я потратил два дня на отчёт, который оказался неверным, потому что не знал: поле status в таблице orders может быть NULL, если заказ ещё не обработан системой.

Но документации по этому поводу не было и узнал я об этом потом только со слов коллег. С тех пор я понял - реляционная модель это не про данные. Это про доверие.

❗️ Таблицы — это интерфейс

В IT мы привыкли к API: чёткие контракты, типы, документация.

➖Реляционная схема — API для данных.
➖Имена таблиц и колонок — часть договора.
➖Типы данных (DATE, BOOLEAN, NUMERIC(10,2)) — гарантии формата.
➖Ограничения (NOT NULL, FOREIGN KEY, CHECK) — правила игры.

Например, если в колонке user_id есть NULL, значит, система допускает анонимные действия. Это бизнес-решение, зафиксированное в схеме (надеюсь).

❗️ Кто участвует в этом договоре?

➖ Разработчики — создают и меняют схему.
➖ Аналитики — читают данные, строят гипотезы, пишут требования.
➖ ML\BI-инженеры — строят витрины и дашборды, обучают модели.
➖ Менеджеры продукта — принимают решения на основе этих данных.

Если договор нарушен (например, внезапно появляются дубли без первичного ключа), все теряют доверие к данным.

❗️ Что ломает договор?

➖ Колонки вроде data_json со "всем подряд" - нет контракта, только хаос.
➖ Отсутствие документации: "Что значит status = 5?"
➖ Изменение типа колонки без уведомления команд юзающих данные (например, INT стал TEXT).
➖ Использование общих таблиц вроде temp_analytics_2025 как совокупного источника истины.

Это как менять API без версионирования - клиенты падают, но никто не знает почему.

❗️ Договор требует ответственности от всех сторон

➖ Разработчик не должен "временно" писать мусор в notes-поле вместо создания новой сущности.
➖ Аналитик не должен строить отчёт на основе недокументированного поля, даже если "оно работает"
➖ Команда должна иметь владельца данных - человека, который следит за целостностью контракта.

❗️ Как укреплять договор?

➖ Именуйте осознанно: order_created_at, а не date1.
➖ Используйте ограничения: если поле не может быть пустым - NOT NULL.
➖ Документируйте семантику: через комментарии в БД (COMMENT ON COLUMN ...) или Data Dictionary. Если вы бизнес/системный аналитик, подробно описывайте поля и логику, например в конфлюенс.
➖ Согласовывайте изменения: даже переименование колонки событие для всей команды.
➖ Уточняйте и уведомляйте: лучше лишний раз переспросить перед внесением изменений в данные и после уведомить заинтересованных, чем потом отвечать на кучу вопросов "а почему теперь так?"

❗️ Данные, это социальный артефакт

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

Посмотрите на любую таблицу в вашей БД. Спросите себя:

➖ Мог бы новичок понять, что означают эти поля?
➖ Есть ли здесь секретные знания, которые живут только в головах коллег?

Если да - вы знаете, с чего начать укреплять договор.

И напоследок анекдот:

Новичок приходит в команду и спрашивает:
— Где почитать про модель данных БД?
— Вся документация в голове у Артёма — отвечает тимлид.
— А как с ним связаться?
— А… он уволился полгода назад.

📱 Подписаться на канал
💻 Курс автора по SQL DDL
🌎 Мой ИТ-стартап

0️⃣ NULL в SQL - не "ничего", а "неизвестно"

Когда вы видите NULL в таблице, интуиция подсказывает: "Это просто пусто. Ничего нет. Поле не заполнено".
Но реляционная модель намеренно отказывается от такого упрощения. Вместо "ничего" она вводит состояние неопределённости: значение существует, но нам о нём ничего не известно. Именно поэтому NULL - это не данные, а метаинформация о недостатке данных.

И эта тонкость ломает привычную булеву логику, заставляя SQL работать с трёхзначной логикой (3VL):

➖ TRUE - утверждение верно,
➖ FALSE - утверждение ложно,
➖ UNKNOWN - мы не можем судить

0️⃣ Почему age = NULL ничего не возвращает?

Рассмотрим запрос:

SELECT name FROM employees WHERE age = NULL;

Логика кажется простой: "выведи всех, у кого возраст не указан"

Но СУБД думает иначе. Выражение вида age = NULL не возвращает ни TRUE, ни FALSE.
Поскольку NULL обозначает отсутствие известного значения, сравнение любого выражения с NULL с использованием стандартных операторов (=, <>, <, >, и т.д.) всегда приводит к логическому значению UNKNOWN.

Согласно семантике WHERE, в результирующий набор включаются только те строки, для которых условие оценивается как TRUE. Значения FALSE и UNKNOWN в этом контексте ведут себя одинаково - соответствующие строки исключаются из вывода.

Следовательно, конструкция из примера никогда не возвращает строк, даже если в столбце age присутствуют значения NULL.

Правильный синтаксис - специальный оператор:

SELECT name FROM employees WHERE age IS NULL; -- также антипод IS NOT NULL

Здесь вы не сравниваете значения, а запрашиваете состояние. Эти предикаты предназначены именно для работы с состоянием неопределённости и возвращают строго TRUE или FALSE.

0️⃣ Поведение агрегатных функций

Большинство агрегатов (SUM, AVG, MAX, MIN) игнорируют NULL. Это не ошибка, это следствие семантики "неизвестно":
➖ Если зарплата неизвестна, её нельзя включать в среднее - это исказит реальность.
➖ Если дата рождения неизвестна, нельзя сказать, кто самый старший.

Пример:

Таблица salaries:
id | amount
1  | 5000
2  | NULL
3  | 7000

Запрос:

SELECT AVG(amount) FROM salaries;  -- Результат: 6000 (а не 4000!)

Если вы сознательно хотите трактовать NULL как 0 (например, "не заплатили - значит, ноль"), используйте COALESCE или CASE:

SELECT AVG(COALESCE(amount, 0)) FROM salaries;  -- Теперь: 4000

Но будьте осторожны, это меняет семантику данных. Вы переходите от "мы не знаем" к "мы знаем, что это ноль"

0️⃣ NULL в JOIN, GROUP BY и ORDER BY

➖ JOIN. Строка с NULL в ключе не совпадёт ни с чем - даже с другой NULL. Потому что NULL = NULL - UNKNOWN, а не TRUE.
➖ GROUP BY. Все NULL в одном столбце группируются в одну группу. Это практичное исключение - иначе агрегация была бы бесполезной.
➖ORDER BY. NULL обычно идут в начале (ASC) или в конце (DESC), но это зависит от СУБД. В PostgreSQL можно управлять:

ORDER BY column NULLS LAST

0️⃣ Практические рекомендации

➖ Никогда не используйте = NULL - только IS NULL / IS NOT NULL.
➖ Явно обрабатывайте NULL в расчётах, если семантика требует замены (через COALESCE, CASE, NULLIF).
➖ Избегайте NOT IN, если подзапрос может вернуть NULL - это классическая ловушка: если в t2. id есть хотя бы один NULL, весь результат будет пустым! Лучше NOT EXISTS или LEFT JOIN ... WHERE t2. id IS NULL.
➖ При проектировании таблицы задайте вопрос: "Это поле может быть неизвестным - или просто необязательным?". Иногда лучше использовать отдельный флаг (is_age_estimated BOOLEAN).

#SQL #NULL

📱 Подписаться на канал
💻 Курс автора по SQL DDL
🌎 Мой ИТ-стартап

🥳Всех с наступающим!

Решил подвести, итоги года для канала.

Создавая его в феврале, я даже не думал, что получу такой крутой отклик от вас. Нас уже +1к, чему я безумно рад.

🏆 Хочу поблагодарить каждого подписчика за то, что читаете мой контент, ставите реакции, пишите коменты. Вы лучшие!

🍑Немного статистики: за этот год, было написано 115 постов, получено 1.8к реакций и 78.8к просмотров

🔥Посты с самым большим количеством реакций:
➖ Null в SQL — не "ничего", а неизвестно
➖ Having в SQL
➖ Junior-ready: выучить SQL и пройти собесы. Часть 1/2

🚀 От себя отмечу ещё пару постов:
➖Реляционная модель это не просто таблицы, это договор между людьми. — тут я немного ударился в философию данных, в следующем году планирую это активно продолжать 😂
➖Он создал MySQL — и потерял миллиарды. История, о которой редко рассказывают — пост нового формата, потом написал ещё несколько таких, как по мне, читать чью-то историю это всегда интересно, ведь за любым ПО всегда стоят люди.
➖SQL Injection: как одна кавычка может взломать базу данных — ну тут все понятно 💻

На самом деле, ещё бы долго продолжал этот список, например, мне нравится серия постов про нормализацию данных или пока еще не полностью законченный обзор по работе с датами и временем

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

Под конец года, писал довольно мало, из-за высокой нагрузки на работе, прочих проектах, в следующем году обещаю исправится, буду писать пост каждую неделю 😆

В общем, увидимся в 2026! 👍

📱 Подписаться на канал
💻 Курс автора по SQL DDL
🌎 Мой ИТ-стартап

👩‍💻 Типы данных в PostgreSQL: как они устроены и почему их выбор имеет значение

Одна из самых распространенных ошибок при проектировании базы данных это выбирать типы данных по принципу "лишь бы поместилось". На самом деле тип данных определяет не только допустимые значения, но и способ их хранения, объем занимаемой памяти, производительность запросов и размер индексов. PostgreSQL предоставляет широкий набор встроенных типов данных, каждый из которых предназначен для решения определенных задач. В этом посте коротко, постарался описать, основные типы которые встречаются в постгре.

Тут кста пост про то как создали постгре 🖥

❗️ Целочисленные типы

Для хранения целых чисел PostgreSQL предоставляет три основных типа:

SMALLINT
INTEGER
BIGINT

➖ SMALLINT занимает 2 байта и хранит значения в диапазоне от -32 768 до 32 767.
➖ INTEGER (или сокращенно INT) занимает 4 байта и является наиболее часто используемым типом. Его диапазон составляет от -2 147 483 648 до 2 147 483 647.
➖ BIGINT занимает 8 байт и используется, когда диапазона INTEGER недостаточно, например для очень больших идентификаторов или счетчиков.

Типы SERIAL, BIGSERIAL и SMALLSERIAL не являются отдельными типами данных. Это специальная запись, которая автоматически создает последовательность (SEQUENCE) и задает значение по умолчанию для соответствующего целочисленного столбца.
При выборе типа рекомендуется использовать минимально достаточный размер. Это позволяет уменьшить объем хранения данных и размер индексов, хотя в современных системах влияние на производительность обычно менее заметно, чем влияние правильно построенных индексов и структуры запросов.

❗️ Числа с фиксированной точностью

Для хранения значений, где важна абсолютная точность, используются типы NUMERIC и DECIMAL.

price NUMERIC(10,2)

Первый параметр определяет максимальное количество цифр, второй, количество цифр после десятичной точки.
Например:

99999999.99

Главное преимущество NUMERIC это возможность хранить десятичные числа с заданной точностью без ошибок представления, характерных для чисел с плавающей точкой. В отличие от типов с плавающей точкой, каждое значение хранится с заданной точностью.
Именно поэтому все финансовые расчеты, бухгалтерские операции и денежные суммы рекомендуется хранить в NUMERIC. Следует учитывать, что операции над такими числами требуют больше вычислений и обычно выполняются медленнее, чем над целыми числами.

❗️ Числа с плавающей точкой

В PostgreSQL используются типы:

REAL
DOUBLE PRECISION

Также поддерживается запись

FLOAT(p)

где значение p определяет необходимую точность. В зависимости от нее постгре автоматически использует либо REAL, либо DOUBLE PRECISION. Если p ≤ 24, используется REAL, иначе (до 53) будет DOUBLE PRECISION. Эти типы реализованы в соответствии со стандартом IEEE 754. Число хранится в виде знака, экспоненты и мантиссы, благодаря чему поддерживается очень широкий диапазон значений. Однако далеко не каждую десятичную дробь можно представить точно в двоичной системе.
Например:

SELECT 0.1 + 0.2;

может вернуть

0.30000000000000004

Это нормальное поведение чисел с плавающей точкой, а не ошибка СУБД. Поэтому REAL и DOUBLE PRECISION подходят для инженерных расчетов, статистики и научных вычислений, но не для хранения денежных сумм.

❗️ Символьные типы

Наиболее часто используются три типа:

CHAR(n)
VARCHAR(n)
TEXT

➖ CHAR(n) хранит строки фиксированной длины. Если фактическая длина меньше указанной, PostgreSQL дополняет значение пробелами до нужного размера.
Такой тип имеет смысл использовать только тогда, когда длина значения всегда одинакова, например для кодов стран или сокращений.
➖ VARCHAR(n) хранит строки переменной длины и дополнительно проверяет, что значение не превышает указанное ограничение.
➖ TEXT также хранит строки переменной длины, но без ограничения размера.

Интересная особенность PostgreSQL заключается в том, что TEXT и VARCHAR используют практически одинаковый механизм хранения. На практике различий в производительности между ними практически нет. Единственное отличие состоит в том, что VARCHAR(n) выполняет дополнительную проверку максимальной длины строки при записи данных. Именно поэтому многие разработчики PostgreSQL предпочитают использовать TEXT, если ограничение длины не является бизнес-требованием.

❗️ Дата и время

Для хранения временных данных PostgreSQL предоставляет несколько специализированных типов:

DATE
TIME
TIMESTAMP
TIMESTAMPTZ

➖ DATE хранит только календарную дату.
➖ TIME содержит только время суток.
➖ TIMESTAMP хранит дату и время без информации о часовом поясе.
➖ TIMESTAMPTZ (Timestamp with Time Zone) хранит момент времени с учетом часового пояса. Внутри PostgreSQL такие значения преобразуются в UTC, а при выводе отображаются в часовом поясе текущей сессии.
Оба типа TIMESTAMP занимают 8 байт и представлены как количество микросекунд относительно внутренней эпохи PostgreSQL. Благодаря этому операции сравнения, сортировки и вычисления интервалов выполняются очень эффективно.

❗️ Логический тип

Для хранения булевых значений используется тип

BOOLEAN

Он занимает 1 байт и поддерживает значения:

TRUE
FALSE
NULL

PostgreSQL также понимает различные формы записи при вводе значения, например 1, 0, yes, no, on, off, автоматически преобразуя их в логические значения.

❗️ Бинарные данные

Для хранения произвольной последовательности байтов используется тип:

BYTEA

Он подходит для хранения изображений, документов, архивов и других бинарных объектов.
Для очень больших файлов постгре также предоставляет механизм Large Objects, который позволяет хранить данные отдельно от основной таблицы и работать с ними потоково, но на самом деле он используется значительно реже, чем BYTEA, и обычно нужен лишь для действительно крупных объектов.

❗️ Специализированные типы PostgreSQL

Одно из преимуществ постгри это наличие типов данных, отсутствующих во многих других СУБД.

➖ UUID - используется для хранения глобально уникальных идентификаторов (пост про юиды тут 😎)

id UUID

UUID занимает 16 байт и позволяет генерировать уникальные идентификаторы без обращения к последовательностям.

➖ JSON и JSONB

JSON
JSONB

JSON хранит исходный текст документа.
JSONB преобразует данные во внутренний бинарный формат, позволяющий создавать индексы и выполнять быстрый поиск по содержимому.
В большинстве случаев именно JSONB является предпочтительным выбором.

➖ ARRAY - PostgreSQL поддерживает массивы как полноценный тип данных.

tags TEXT[]
scores INTEGER[]

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

➖ ENUM - Позволяет определить собственный тип с фиксированным набором значений. Например:

CREATE TYPE order_status AS ENUM (
    'new',
    'paid',
    'shipped',
    'completed'
);

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

Тип данных в PostgreSQL определяет значительно больше, чем допустимый формат значения. Он влияет на внутреннее представление данных, объем хранения, размер индексов, скорость выполнения запросов и возможности оптимизатора.
Чем точнее выбран тип данных на этапе проектирования схемы, тем эффективнее будет работать база данных при росте объема информации. Именно поэтому грамотное проектирование БД начинается не с написания запросов, а с выбора подходящих типов данных.

#SQL #Типы_данных #PostgreSQL

📱 Подписаться на канал
💻 Курс автора по SQL DDL
👩‍💻Nodus