Дональд Чемберлин и SQL: язык запросов для людей

Кто такой Дональд Чемберлин и почему о нём говорят

Дональд Чемберлин — один из тех людей, чьи идеи незаметно формируют повседневную работу миллионов специалистов. В 1970‑х он работал в IBM и вместе с коллегами (в частности, с Рэймондом Бойсом) участвовал в создании языка запросов, который сначала назывался SEQUEL, а затем стал известен как SQL. Если вы когда-либо писали SELECT ... FROM ... WHERE ..., строили отчёты по продажам или разбирались, почему «не сходится отчёт», вы так или иначе касались наследия Чемберлина.

Почему важно помнить не только технологии, но и людей

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

Именно здесь вклад Чемберлина особенно заметен: SQL задумывался как язык, который ближе к человеческой логике, чем к низкоуровневому программированию. Вместо пошаговых инструкций — описание того, какой результат нужен. Это снизило порог входа, сделало работу с реляционными БД массовой и в итоге превратило базы данных из «инструмента для избранных» в стандартный компонент бизнеса и софта.

О чём будет эта статья

Дальше — путь SQL и причины его успеха без лишней мистики:

• что было до SQL и почему реляционная модель изменила правила игры;
• как SEQUEL превратился в SQL и почему название — лишь верхушка айсберга;
• почему SQL воспринимается «понятным человеку» и что за этим стоит;
• базовые конструкции (SELECT, FROM, WHERE), соединения (JOIN), группировки и отчёты;
• изменения данных, транзакции и как не потерять важное;
• стандарты и диалекты: почему один и тот же запрос может вести себя по-разному;
• практические темы: производительность, безопасность и читаемость запросов;
• где SQL особенно силён — и когда разумнее выбрать другой подход.

В итоге сложится цельная картина: от личности и замысла — к повседневной практике, с которой сталкиваются команды и компании каждый день.

Что было до SQL: реляционная модель и боль доступа к данным

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

Реляционная модель в двух словах

Реляционный подход предлагает хранить данные в таблицах. Каждая таблица состоит из строк (записей) и столбцов (полей). Например, таблица «Клиенты» может содержать строки с конкретными людьми и столбцы вроде id, «имя», «город».

Чтобы таблицы можно было связывать между собой, используются ключи. Обычно есть:

• первичный ключ — уникальный идентификатор строки (например, customer_id);
• внешний ключ — ссылка на строку в другой таблице (например, order.customer_id → customers.customer_id).

Главная идея: данные описываются как набор фактов, а не как цепочка шагов «как именно их найти». Это звучит просто — но до SQL именно «как найти» и было основной проблемой.

Почему доступ к данным был болью

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

• запросы превращались в длинные программы вместо коротких выражений;
• одно и то же «что получить» приходилось переписывать под разные случаи «как пройти»;
• изменение структуры данных ломало код, потому что логика была привязана к физическому хранению.

Почему понадобился «человеческий» язык запросов

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

От SEQUEL к SQL: рождение языка запросов

История SQL начинается не с «готового стандарта», а с попытки сделать общение с реляционной базой данных простым и естественным. В IBM в начале 1970‑х Дональд Чемберлин и Рэймонд Бойс работали над экспериментальной системой System R и искали язык, который позволит формулировать запросы без погружения в детали хранения данных.

Что такое SEQUEL и почему появилось это название

Первое имя языка было SEQUEL — Structured English Query Language («структурированный английский язык запросов»). Оно подчёркивало главную идею: запрос должен выглядеть почти как фраза на человеческом языке и быть читаемым не только для программистов.

Название было намеренно «говорящим»: разработчики хотели, чтобы человек мог написать запрос, ориентируясь на смысл («покажи мне такие-то записи»), а не на устройство файлов, индексов и порядок выполнения операций.

Запрос как описание результата, а не пошаговый алгоритм

Ключевой поворот — декларативность. Вместо того чтобы задавать алгоритм вида «возьми таблицу A, потом пробеги по строкам, потом сопоставь с таблицей B», пользователь описывает какой результат он хочет получить:

• какие данные выбрать;
• из каких таблиц;
• по каким условиям;
• как сгруппировать или отсортировать.

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

Почему закрепилось имя SQL и как оно читается/произносится

Позже название SEQUEL пришлось сократить до SQL (в том числе из-за вопросов с правами на торговую марку). Так появилось короткое имя, которое закрепилось в индустрии.

Произношение встречается разное: по-английски часто говорят «эс-кью-эл» (S-Q-L) или «сиквел» (sequel — по старой привычке). По-русски обычно произносят «эс-кью-эл» — важнее контекст, чем вариант.

Почему SQL оказался «понятным человеку»

SQL «зашёл» не потому, что был самым изящным языком на свете, а потому что совпал с тем, как люди формулируют запросы к данным. Вместо пошагового описания пути по записям он позволил говорить о результате.

Декларативность: «что получить», а не «как искать»

Главная идея — декларативный подход. Вы описываете, что хотите увидеть: какие строки, какие столбцы, с какими условиями. А как именно база данных дойдёт до ответа — перебором, по индексу, через сортировку или другим способом — решает сама система.

Это снижает порог входа: пользователю не нужно думать категориями алгоритмов и структуры хранения. По сути, вы формулируете «вопрос», а не «инструкцию».

Минимальный словарь и «почти человеческая» фраза

У SQL небольшой набор ключевых слов, которые интуитивно читаются даже без большого опыта: SELECT, FROM, WHERE, позже — JOIN, GROUP BY, ORDER BY. Конструкция напоминает обычную речь: «выбери это из того, где выполняется условие». Такая близость к естественным формулировкам делает запросы узнаваемыми и удобными для обсуждения в команде.

Логика запроса отдельно, хранение отдельно

Ещё одна причина понятности — разделение смысла запроса и физической реализации. Один и тот же SQL‑запрос остаётся корректным, даже если таблицы переехали на другой диск, появились индексы или изменился план выполнения. Это помогает думать о данных на уровне «какие факты нужны», а не «в какой части файла они лежат».

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

Основы SQL: SELECT, FROM, WHERE без магии

SQL иногда пугает новичков тем, что выглядит как «заклинание». На деле в его основе простая идея: выбрать нужные столбцы (SELECT), указать источник данных (FROM) и отфильтровать строки (WHERE).

Что делают SELECT, FROM и WHERE

FROM отвечает на вопрос: «из какой таблицы (или набора таблиц) берём данные». Это стартовая точка.

SELECT — «что именно показать». Можно выбрать один столбец, несколько или вычисления.

WHERE — «какие строки оставить». Это фильтр, который убирает лишнее до того, как вы увидите результат.

Пример на выдуманных данных

Представим две таблицы: users (пользователи) и orders (заказы). Хотим получить имена пользователей и суммы заказов, но только для оплаченных заказов дороже 1000.

SELECT u.name, o.total
FROM users u
JOIN orders o ON o.user_id = u.id
WHERE o.status = 'paid'
  AND o.total > 1000;

Даже если вы ещё не уверены в JOIN, прочитать запрос можно «по-русски»: показать имя и сумму, взять пользователей и их заказы, оставить только оплаченные и дорогие.

Как человек читает запрос — и как он выполняется

Обычно человек читает сверху вниз: SELECT → FROM → WHERE. Но логически база данных делает иначе:

1. FROM (собирает набор строк из таблиц)
2. WHERE (фильтрует строки)
3. SELECT (формирует итоговые столбцы)

Из-за этого нельзя в WHERE ссылаться на псевдонимы из SELECT (например, SELECT total*0.2 AS tax ... WHERE tax > 100 — так не сработает).

Частые ошибки новичков

1) Фильтрация «не там». Условие должно быть в WHERE, а не «в голове». Если фильтр забыли — запрос вернёт корректные, но лишние данные.

2) NULL — не «пустая строка» и не ноль. NULL означает «неизвестно». Поэтому col = NULL никогда не сработает. Нужно:

WHERE col IS NULL

3) Сравнения и логика. = — это сравнение, а не «присваивание». И аккуратнее с AND/OR: без скобок легко получить неожиданный результат.

Освоив эти три кирпичика, вы уже можете писать запросы, которые отвечают на реальные вопросы бизнеса — без магии и без догадок.

Соединения таблиц: JOIN, который не пугает

Реляционная база данных хороша тем, что данные не приходится складывать «в одну огромную таблицу». Клиенты — отдельно, заказы — отдельно, товары — отдельно. Но как только появляется вопрос «покажи клиентов вместе с их заказами», нужен способ связать таблицы между собой. Эту задачу и решает JOIN.

Зачем вообще нужны JOIN

JOIN позволяет собрать цельную картину из нескольких таблиц: вывести список заказов с именем клиента, показать товары в конкретном заказе, построить отчёт по продажам по категориям — всё это примеры «склейки» данных по общим ключам (например, customer_id).

INNER JOIN vs LEFT JOIN — простая разница

Представим две таблицы: customers (клиенты) и orders (заказы). У некоторых клиентов заказов ещё нет.

SELECT
  c.id,
  c.name,
  o.id AS order_id,
  o.created_at
FROM customers AS c
INNER JOIN orders AS o
  ON o.customer_id = c.id;

INNER JOIN вернёт только тех клиентов, для кого нашлась пара в orders. Клиент без заказов «исчезнет» из результата.

SELECT
  c.id,
  c.name,
  o.id AS order_id,
  o.created_at
FROM customers AS c
LEFT JOIN orders AS o
  ON o.customer_id = c.id;

LEFT JOIN вернёт всех клиентов из левой таблицы (customers). Если заказа нет, поля из orders будут NULL. Это удобно для вопросов вида «кто ещё ничего не купил?».

Опасности: дубли и «размножение» строк

Главный сюрприз для новичков: JOIN может увеличить число строк. Если у клиента 5 заказов, то одна строка клиента превратится в 5 строк (по одной на заказ). Это нормально, но легко получить неверные итоги в отчётах, если потом суммировать или считать строки «как есть».

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

Практика, которая спасает

Явно пишите условие ON (не полагайтесь на неочевидные сокращения), используйте понятные алиасы (c для customers, o для orders) и держите в голове кардинальность связи: «один-к-одному», «один-ко-многим» или «многие-ко-многим». Тогда JOIN становится предсказуемым и перестаёт пугать.

Агрегации и GROUP BY: как строить отчёты

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

Зачем нужны агрегаты: COUNT, SUM, AVG, MIN, MAX

• COUNT — сколько строк (или сколько непустых значений в столбце).
• SUM — сумма, например выручка.
• AVG — средний чек.
• MIN/MAX — самый ранний заказ, самая большая сумма и т. п.

Важно: агрегаты «схлопывают» набор строк. Если вы не группируете данные, результат обычно будет одной строкой на весь запрос.

GROUP BY и HAVING: фильтрация строк vs фильтрация групп

WHERE фильтрует строки до агрегирования. HAVING фильтрует группы после того, как вы сделали GROUP BY.

Пример логики:

• WHERE: «берём только оплаченные заказы за декабрь».
• GROUP BY: «группируем по клиентам».
• HAVING: «оставляем только клиентов, у кого сумма покупок больше 50 000».

Типичные ловушки

1. Неагрегированные поля в SELECT. Если в SELECT есть столбец, который не обёрнут в агрегат (SUM/COUNT/…) — он должен быть в GROUP BY. Иначе СУБД либо выдаст ошибку, либо результат будет непредсказуемым.

2. Группировка по лишним столбцам. Частая ошибка: добавить в GROUP BY дату/время заказа, а потом удивляться, что вместо отчёта «по клиентам» получились тысячи строк — по каждой транзакции.

3. COUNT(*) vs COUNT(поле). COUNT(*) считает строки, COUNT(поле) — только строки, где поле не NULL.

Пример: отчёт по заказам за период

SELECT
  o.customer_id,
  COUNT(*)        AS orders_cnt,
  SUM(o.total)    AS revenue,
  AVG(o.total)    AS avg_check,
  MIN(o.created_at) AS first_order_at,
  MAX(o.created_at) AS last_order_at
FROM orders o
WHERE o.status = 'paid'
  AND o.created_at >= '2025-01-01'
  AND o.created_at <  '2025-02-01'
GROUP BY o.customer_id
HAVING SUM(o.total) >= 50000
ORDER BY revenue DESC;

Такой запрос читается как «история покупок по каждому клиенту», а результат уже похож на бизнес-отчёт: количество заказов, выручка и средний чек — в одной таблице.

Изменение данных и транзакции: как не потерять информацию

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

INSERT/UPDATE/DELETE: простые команды, серьёзные последствия

• INSERT добавляет новые строки. Полезная привычка — явно перечислять поля, чтобы изменения в схеме не сломали запрос.
• UPDATE меняет данные. Главный риск — забытый WHERE, который обновит всё.
• DELETE удаляет строки. Ошибка в условии может стереть больше, чем планировалось.

Мини-шаблон осторожного обновления:

BEGIN;

SELECT *
FROM customers
WHERE status = 'inactive';

UPDATE customers
SET status = 'archived'
WHERE status = 'inactive';

COMMIT;

Транзакции: атомарность и откат

Транзакция — это «пакет» изменений, который выполняется целиком или не выполняется вовсе. Пока вы не сделали COMMIT, изменения можно отменить командой ROLLBACK. Это особенно важно, когда вы обновляете несколько таблиц и хотите избежать частично выполненной операции.

Практическое правило: если действие влияет на деньги, остатки, права доступа или предполагает массовые правки — делайте это в транзакции.

Уровни изоляции — коротко, по-человечески

Уровень изоляции отвечает за то, насколько ваша транзакция «видит» параллельные изменения других.

• READ COMMITTED: вы видите только подтверждённые изменения (часто значение по умолчанию).
• REPEATABLE READ: данные, прочитанные в транзакции, не «прыгают» при повторном чтении.
• SERIALIZABLE: максимальная строгость, но может снижать параллельность.

Практический совет: сначала SELECT

Перед UPDATE или DELETE сначала выполните тот же WHERE в SELECT и убедитесь, что список строк верный. Если результат удивляет — правьте условие, а не данные.

Стандарты и диалекты SQL: почему «SQL бывает разным»

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

Что такое стандарт SQL и зачем он нужен

Стандарт SQL (ANSI/ISO) — это набор правил: какие ключевые слова существуют, как устроены типы данных, что должно поддерживаться в транзакциях, какие функции и операторы обязаны работать одинаково.

Зачем это нужно:

• чтобы у SQL была общая основа, понятная всем;
• чтобы приложения и специалисты могли переносить знания между системами;
• чтобы у СУБД была «точка отсчёта», от которой можно расширяться.

Почему существуют диалекты

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

Типичные различия:

• автонумерация идентификаторов (AUTO INCREMENT/IDENTITY/SEQUENCE);
• функции строк и дат (форматирование, разница дат);
• LIMIT/OFFSET vs FETCH FIRST;
• особенности upsert (MERGE или аналоги).

Как писать переносимый SQL

Если вам не нужна уникальная функция конкретной СУБД — не привязывайтесь к ней.

Практика:

• опирайтесь на базовые SELECT/FROM/WHERE/JOIN/GROUP BY;
• аккуратно используйте функции дат и строк (или выносите преобразования в приложение);
• явно задавайте типы и имена столбцов, избегайте «магических» преобразований;
• пишите запросы так, чтобы их можно было тестировать на небольших наборах данных.

Что проверить при миграции между СУБД

При переносе чаще всего ломаются не SELECT, а «края» системы:

• типы данных и их диапазоны (особенно даты, деньги, булевы значения);
• поведение NULL, сравнения, сортировки и коллации;
• транзакции и уровни изоляции;
• DDL (ограничения, индексы, генерация ключей);
• специфичные расширения: upsert, JSON-функции, оконные функции, CTE-рекурсия.

Хорошее правило: сначала добейтесь корректности на стандартных возможностях SQL, а оптимизации и «фишки» диалекта добавляйте осознанно и точечно.

SQL в реальности: производительность и безопасность

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

Что влияет на скорость запросов

Скорость редко упирается в «сам SQL». Обычно дело в сочетании факторов: объём данных, наличие индексов и селективность условий (насколько фильтр сужает набор строк).

Если таблица маленькая, почти любой запрос быстрый. Но на миллионах строк разница между фильтром по индексируемому столбцу и фильтром «как-нибудь» становится огромной. Важно и то, сколько данных вы просите вернуть: выбрать 3 нужных столбца обычно дешевле, чем SELECT *.

Как понимать EXPLAIN без привязки к СУБД

EXPLAIN показывает план выполнения — то есть какой «маршрут» выберет система: прочитать всю таблицу, использовать индекс, как соединить таблицы, где посчитать фильтры.

На уровне идеи смотрите на два вопроса:

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

Если план говорит «прочитаю почти всё», не ждите скорости — лучше изменить запрос или схему индексов.

Безопасность: параметризованные запросы

Главная защита от SQL-инъекций — не склеивать SQL строками с пользовательским вводом. Вместо этого используйте параметризованные запросы (плейсхолдеры), где значения передаются отдельно от текста запроса. Тогда ввод воспринимается как данные, а не как часть команды.

Практика, которая помогает сразу

• Ограничивайте выборки: LIMIT, пагинация, разумные условия WHERE.
• Выбирайте нужные столбцы вместо SELECT *.
• Старайтесь фильтровать по индексируемым полям и избегать преобразований над ними в условии (например, функций над столбцом), если это ломает использование индекса.

Короткая связка с практикой разработки

SQL редко живёт «в вакууме»: обычно он становится частью приложения, админки, внутреннего сервиса или аналитического дашборда. Если вы собираете такие решения быстро (MVP, внутренние инструменты, витрины данных), удобно, когда рядом есть платформа, которая ускоряет путь от идеи до работающего продукта.

Например, в TakProsto.AI можно в формате чата описать нужный сценарий (сущности, таблицы, отчёты, фильтры), а затем собрать веб‑приложение на React с бэкендом на Go и PostgreSQL. Это хорошо ложится на философию SQL «сначала описываем результат»: вы формулируете требования, платформа помогает превратить их в приложение, при этом поддерживаются экспорт исходников, деплой, снапшоты и откат изменений.

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

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

Стиль: форматирование и единый подход

Договоритесь о простых правилах и придерживайтесь их всегда: переносы строк, отступы и единый регистр ключевых слов (например, всё UPPERCASE). Условия в WHERE лучше выравнивать построчно — так видно, что именно фильтруется, и легче добавлять или удалять части.

Практика, которая быстро окупается:

• Один логический блок — одна зона ответственности (SELECT — столбцы, FROM — источники, WHERE — фильтры).
• Явный порядок условий: сначала «сужающие» (даты, статусы), затем уточняющие.
• Не полагаться на «порядок столбцов» — всегда перечислять поля в SELECT.

Имена и алиасы: запрос как самодокумент

Имена таблиц и полей должны говорить сами за себя. Если у вас несколько таблиц, используйте короткие, но осмысленные алиасы: u для users, o для orders — нормально, а t1, t2 почти всегда ухудшают понимание. Для вычисляемых столбцов давайте явные названия: total_amount, first_order_date.

Комментарии и CTE (WITH): разложить сложное по шагам

Если запрос длинный, разбейте его на шаги через CTE: так появляется «сюжет» запроса — подготовка данных, фильтрация, агрегация.

WITH paid_orders AS (
  SELECT
    o.user_id,
    o.amount,
    o.paid_at
  FROM orders o
  WHERE o.status = 'paid'
),
monthly AS (
  SELECT
    user_id,
    DATE_TRUNC('month', paid_at) AS month,
    SUM(amount) AS revenue
  FROM paid_orders
  GROUP BY user_id, DATE_TRUNC('month', paid_at)
)
SELECT *
FROM monthly
WHERE revenue > 1000;

Комментарии оставляйте там, где есть нетривиальная бизнес-логика (например, почему исключаются определённые статусы), а не там, где и так всё очевидно.

Мини-чек-лист ревью

Перед тем как «сливать» запрос:

• Корректность: не дублируются ли строки из‑за JOIN, верные ли фильтры по датам.
• Читаемость: понятны ли имена, можно ли следовать запросу сверху вниз.
• Ожидаемый объём: сколько строк вернётся, нет ли случайного «взрыва» результата (особенно при соединениях).

Где SQL сильнее всего — и где стоит выбрать другое решение

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

Где SQL помогает больше всего

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

В хранилищах данных и BI SQL раскрывается ещё сильнее: отчёты, витрины, сегменты клиентов, мониторинг метрик. Агрегации, фильтры и соединения позволяют описывать логику отчёта так, чтобы её можно было обсудить с аналитиками и бизнесом, а затем воспроизвести в любом окружении. Плюс — интеграции: множество систем «говорят» через SQL или легко подключаются к источникам, где SQL является базовым интерфейсом.

Когда SQL неудобен

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

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

Как сочетать SQL с другими подходами

На практике SQL редко живёт в одиночку. ORM помогает разработчикам работать с данными на уровне объектов, а SQL оставляют для сложных выборок и отчётов. Представления делают запросы проще и единообразнее, а материализованные представления ускоряют тяжёлые расчёты, когда отчёты нужны «здесь и сейчас».

Итог

Вклад Дональда Чемберлина — не только в синтаксис, а в идею: дать индустрии язык, на котором можно формулировать запросы к данным относительно человеческим способом. SQL не обязан закрывать все сценарии, но именно он стал универсальной точкой сборки для данных, аналитики и прикладных систем — от первых реляционных экспериментов до современных продуктов, которые строятся вокруг PostgreSQL и понятных запросов к данным.