Что такое SQL и какие бывают диалекты

От модели к языку

В прошлом уроке мы разобрались, как реляционная модель раскладывает данные по таблицам, строкам и колонкам и как таблицы связываются друг с другом через значения. Это была теория «как оно устроено». Но если у тебя есть таблица с пользователями, тебе нужен какой-то способ говорить с базой: «покажи мне всех, кто зарегистрировался в этом месяце», «добавь нового пользователя», «обнови email у пятого». Просто открыть файл и поправить руками не выйдет — данные живут внутри СУБД, и достучаться до них можно только через её собственный интерфейс.

Этот интерфейс — общий для почти всех реляционных баз и называется SQL. Аббревиатура расшифровывается как Structured Query Language — «язык структурированных запросов». Произносят его обычно как «эс-кью-эль» или просто «сиквел». Это второй главный кирпичик, без которого реляционные БД не существуют: модель — что мы храним, SQL — как мы с этим разговариваем.

Освоить SQL стоит хотя бы потому, что он переживает технологии. Языки программирования сменяют друг друга каждые несколько лет, фреймворки рождаются и умирают, но SQL живёт с 1970-х и продолжает быть основным способом работы с данными в банках, маркетплейсах, играх, соцсетях, аналитике, телекоме. Поэтому время, вложенное в SQL, окупается долго.

Декларативный язык: «что», а не «как»

Главное отличие SQL от привычных языков программирования (Python, JavaScript, Java) — он декларативный. Это значит, что ты описываешь результат, который хочешь получить, а не пошаговый алгоритм его получения. СУБД сама придумывает, как выполнить запрос быстрее всего: какой порядок чтения таблиц выбрать, какие индексы задействовать, как распараллелить работу.

Сравни два подхода. Императивный (как ты привык писать на обычных языках) — это «открой файл, прочитай первую строку, проверь поле age, если больше 30 — запиши в результат, иначе пропусти, перейди к следующей строке, повтори». Декларативный (как в SQL) — это «дай мне записи, где age больше 30». Никакого «открой», «прочитай», «перейди к следующей» — только декларация желания.

Чтобы это было нагляднее, вот условный псевдокод императивного варианта:

открыть файл users.csv
для каждой строки:
    если возраст > 30:
        добавить строку в результат
закрыть файл
вывести результат

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

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

Стандарт SQL и почему он не покрывает всё

SQL — это не просто соглашение между разработчиками, у него есть формальный международный стандарт: ISO/IEC 9075. Первая версия стандарта вышла в 1986 году, потом он много раз обновлялся (SQL-89, SQL-92, SQL:1999, SQL:2003, SQL:2008, SQL:2011, SQL:2016, SQL:2023). Каждое обновление добавляет новые возможности: окно над данными, регулярные выражения, JSON, временные таблицы и так далее.

Звучит так, будто все базы должны бы говорить на одном языке. Но на практике — нет, и причины простые:

Стандарт огромен и сложен. Полная реализация SQL:2016 — это тысячи страниц спецификации, и далеко не каждая СУБД поддерживает все его возможности.
Стандарт идёт за индустрией с задержкой. Сначала какая-нибудь СУБД (часто PostgreSQL или Oracle) реализует новую полезную фичу по-своему, и только через несколько лет это попадает в стандарт.
Исторические решения. Некоторые СУБД появились до стандарта или раньше определённой его редакции, и ломать совместимость со старым кодом своих пользователей они не хотят.

Поэтому каждая популярная СУБД говорит на своём диалекте SQL. Базовая часть совпадает почти везде (SELECT, INSERT, UPDATE, DELETE, CREATE TABLE, типы данных, простые операторы) — её ты выучишь один раз и сможешь применять везде. А специфические возможности — типы данных, оптимизации, расширенный синтаксис — разнятся.

Категории SQL-команд

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

DDL — Data Definition Language, язык определения данных. Команды для создания, изменения и удаления структуры базы: таблицы, колонки, ограничения, индексы. «Скажи базе, как должны выглядеть наши данные».
DML — Data Manipulation Language, язык манипуляции данными. Команды, которые меняют содержимое: добавляют, обновляют и удаляют строки. «Запиши, поменяй, сотри».
DQL — Data Query Language, язык запросов. Команды, которые читают данные, ничего не меняя. «Покажи мне».
DCL — Data Control Language, язык управления доступом. Кому можно читать, кому писать, кому создавать таблицы. «Раздай права».
TCL — Transaction Control Language, язык управления транзакциями. Подтверждение и откат пакетов изменений. «Зафиксируй то, что я сделал, или забудь, как страшный сон».

Большую часть курса мы проведём в DQL (читая данные) и DML (меняя их), а к концу затронем DDL (создание таблиц) и TCL (транзакции). DCL встретится только в самых общих чертах — раздачу прав обычно делает администратор БД, а не разработчик повседневно.

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

Популярные диалекты: краткий обзор

Теперь — про конкретные СУБД и их диалекты. Расскажу о пяти самых распространённых, чтобы ты понимал, в какой ты «экосистеме», когда наткнёшься на ту или иную базу.

Диалект	Лицензия	Типичная сфера	Ключевая особенность
PostgreSQL	Open source	Веб-сервисы, аналитика, стартапы, высоконагруженные продукты	Самый «академически правильный»: следует стандарту, богатые типы
MySQL	Open source	Веб-сайты, e-commerce, классические LAMP-стэки	Простая, быстрая на типовых задачах, очень популярна исторически
SQLite	Public domain	Мобильные приложения, тесты, локальные хранилища	Это файл, а не сервер. Подключение и обслуживание — почти ноль
MS SQL Server	Проприетарная	Корпоративные продукты на стеке Microsoft	Глубокая интеграция с .NET и Windows-инфраструктурой
Oracle Database	Проприетарная	Банки, телеком, госструктуры, тяжёлые корпоративные системы	Самая «зрелая», самая сложная в эксплуатации, самая дорогая

PostgreSQL — пожалуй, лучший выбор по умолчанию для современных проектов. Он бесплатный, очень близкий к стандарту, поддерживает кучу продвинутых типов (массивы, JSON, географические данные) и имеет отличное сообщество.

MySQL долго был «дефолтом» веба. Сейчас его всё чаще заменяют PostgreSQL, но огромное число существующих сайтов и сервисов до сих пор живут на MySQL — поэтому совсем игнорировать его не получится.

SQLite — особенный зверь. Он не требует отдельного процесса, он целиком умещается в один файл, и подключение к нему — это просто открытие файла. Поэтому SQLite встраивают в приложения: твой телефон, скорее всего, прямо сейчас держит десяток баз SQLite (контакты, история сообщений, настройки приложений). Для обучения SQL — идеальный вариант, потому что не нужно ставить и настраивать сервер.

MS SQL Server и Oracle — это «корпоративный» сегмент. Если ты работаешь в большой компании, особенно в банке или телекоме, ты с ними столкнёшься. Принципы у них те же, что у PostgreSQL и MySQL, но синтаксис в нюансах отличается, и стоят они дорого.

Есть ещё много других баз — MariaDB (форк MySQL), DuckDB (для аналитики), CockroachDB (распределённая, говорит на диалекте PostgreSQL) — но углубляться в них сейчас не имеет смысла. Для нашего курса хватит понимания, что мир реляционных СУБД устроен как «одна общая база и много разных диалектов сверху».

Чем именно отличаются диалекты

Чтобы ты понимал, насколько глубоки отличия (на самом деле — не очень), приведу несколько типичных мест, где диалекты расходятся:

Имена и набор типов данных. Например, целое число в PostgreSQL может называться INTEGER, в MySQL — INT, в SQLite — тоже INTEGER, но с особенностями. Текст хранится в TEXT / VARCHAR / CHAR с разными правилами длины и кодировки.
Автоинкрементные идентификаторы. Та самая колонка id, которая сама растёт от строки к строке, объявляется по-разному: SERIAL или GENERATED AS IDENTITY в PostgreSQL, AUTO_INCREMENT в MySQL, INTEGER PRIMARY KEY AUTOINCREMENT в SQLite.
Функции для работы со строками и датами. Получить текущую дату, склеить две строки, найти подстроку — синтаксис может разниться. В одной СУБД это NOW(), в другой CURRENT_TIMESTAMP, в третьей и так и этак.
Расширения вне стандарта. Полнотекстовый поиск, работа с JSON, географические запросы, оконные функции, рекурсивные запросы — в каждой СУБД своя степень поддержки, и иногда — свой синтаксис.
Поведение в граничных случаях. Например, что произойдёт при попытке вставить слишком длинную строку в колонку фиксированной длины: одна СУБД молча обрежет, другая выдаст ошибку, третья предложит настройку.

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

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

Зачем этот курс делает упор на «общую часть»

Мы будем строить теорию вокруг того, что работает в большинстве популярных СУБД, с акцентом на PostgreSQL и SQLite (их легко поставить, они бесплатны, у них чистая документация). Когда тебе встретится действительно специфичная для одной СУБД фича, я буду это помечать. Главная ценность — научить тебя «думать на SQL», а не запомнить точный набор флагов одного конкретного движка.

Считай, что SQL — это как английский: есть один общий язык, на нём понимают почти везде, и есть локальные диалекты с особенностями. Овладеть «общим английским» достаточно, чтобы быть полезным где угодно; нюансы американского или британского варианта — это уже надстройка, которую ты выучишь на месте.

Проверь себя

Если бы стандарт SQL покрывал 100% возможностей всех СУБД и все его строго соблюдали — нужны ли были бы диалекты?
К какой из категорий (DDL, DML, DQL, DCL, TCL) относится команда «покажи всех пользователей, зарегистрированных в этом месяце»? А «удали все заказы старше года»?
Чем декларативный язык принципиально отличается от императивного? Можно ли сказать, что декларативный «проще» в общем смысле?

Что унести из урока

SQL — это декларативный язык работы с реляционными БД. Ты описываешь результат, СУБД сама решает как его получить.
У SQL есть формальный стандарт ISO/IEC 9075, но ни одна СУБД не реализует его на 100%, поэтому существуют диалекты.
Команды SQL делятся на пять категорий: DDL (структура), DML (изменение данных), DQL (чтение), DCL (права), TCL (транзакции).
Самые популярные диалекты — PostgreSQL, MySQL, SQLite, MS SQL Server, Oracle. Базовый синтаксис у них почти одинаков; различия — в типах, функциях и расширениях.
В этом курсе мы делаем упор на общую часть, чтобы знание было применимо в любой СУБД, и берём за рабочих лошадей PostgreSQL и SQLite.

Что дальше

Теории на сегодня хватит. В следующем уроке мы перейдём к практическому шагу: установим себе пару СУБД (или воспользуемся онлайн-песочницей) и подготовим всё, чтобы наконец-то отправить базе свою первую команду. Откроем терминал, поставим инструменты — и в уроке 1-5 уже сделаем первый запрос.

Что такое SQL и какие бывают диалекты