📜 История SQL — от лабораторной идеи до «языка данных» № 1

Как появился самый известный язык работы с базами, почему он едва не остался «Сиквелом» и какие любопытные факты о нём редко всплывают в учебниках.

1. Всё началось с таблицы на бумаге

- 1970 г. — британский математик Эдгар Ф. Кодд публикует культовую статью *“A Relational Model of Data for Large Shared Data Banks”*.
- В ней впервые прозвучала идея: хранить данные в виде связанных таблиц, а не как запутанные иерархии (IMS) или сетевые графы (Codasyl).
- Коллеги в IBM скептически называли это «бумагой на буквы», но разрешили сделать прототип, чтобы проверить утопию Кодда на практике.

2. SEQUEL — «английский» запрос к таблицам

- 1973–1974 гг. — в лаборатории IBM San José (ныне Almaden) двое молодых исследователей, Дональд Чемберлин и Рэймонд Бойс, берутся за проект System R.
- Чтобы обращаться к реляционным таблицам, они придумывают Structured English QUEry Language — SEQUEL.
- Ключевая фишка — запросы выглядят почти как английские предложения:

    SELECT name, salary
      FROM employees
     WHERE dept = 'R&D';
      

- В 1974‑м публикуют первую спецификацию; академики критикуют за «слишком поверхностный английский», но программисты в восторге.

3. Почему SEQUEL стал SQL

- Торговая марка “SEQUEL” уже принадлежала авиастроительной компании *Hawker Siddeley*.
- IBM, опасаясь суда, в 1976 г. официально отказывается от «E» и оставляет SQL (Structured Query Language).
- *Небольшая путаница осталась навсегда: кто‑то произносит «эс‑кью‑эл», кто‑то — «сиквел».*

4. Коммерческий взлёт


- 1978 | Первая демонстрация System R внутри IBM | показала, что SQL работает быстрее ожиданий |
- 1979 | Стартап Relational Software (позже Oracle**) выпускает **Oracle V2 — первый коммерческий SQL‑движок | IBM ещё не успела выйти на рынок
- 1981 | IBM выпускает SQL/DS для мейнфреймов | стандарт де‑факто закрепляется
- 1983 | Дебют DB2 — теперь SQL есть почти в каждом крупном банке

5. Стандартизация и эволюция

- ANSI SQL‑86 → SQL‑92 (появился `JOIN ... ON`) → SQL:1999 (рекурсия, триггеры) → SQL:2003 (XML) → … → SQL:2023 (JSON, property graphs).
- Каждые 3–5 лет комитет добавляет «модные» возможности, но 90 % повседневных запросов всё ещё укладываются в синтаксис 1980‑х.

6. Забавные факты, которые украсят small talk 🍸

1. NULL ≠ 0 и NULL ≠ NULL — «неизвестное значение» нарушает законы логики, за что его зовут *“пятой ногой”* реляционной алгебры.
2. `SELECT *` — наследие печати на станке. Звёздочка означала «все колонки», чтобы не писать их руками в 132‑символьных перфокартах.
3. Команда GO в MS SQL Server не принадлежит стандарту SQL — это директива из старого клиента isql.
4. В Oracle долго не было LIMIT, а в MySQL —QL — от лабора Поэтому админы шутили: «истинный межплатформенный SQL — это `SELECT 1;`».
5. Первый SQL‑вирус — червь *Slammer* (2003) — парализовал интернет за 10 минут через уязвимость в SQL Server 2000.
6. SQL — декларативный язык, но внутри СУБД каждый SELECT превращается в процедурный план.
7.Ф. Кодд публикуетпридумали позже, чемлабораторн Сначала удалять целую БД казалось слишком опасным.

7. Почему SQL живёт дольше модных NoSQL‑наследников

- Математическая база. Таблицы + операции Кодда образуют алгебру с предсказуемой оптимизацией.
- Стандарты и переносимость. Код двадцатилетней давности можно запустить в современной Postgres или MariaDB.
- Большая экосистема. От Excel‑плагинов до BigQuery — везде так или иначе поддерживается SQL‑диалект.
- Сопротивляемость моде. Каждый «убийца SQL» (MapReduce, GraphQL, документные БД) в итоге добавляет свой адаптер SELECT ….

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

https://www.youtube.com/shorts/EuFjzuVHkHE

@sqlhub -подписаться

Друзья, мы создали канал с книгами по SQL и залили туда наверное самую большую подборку книг по SQL. Около 200 книг. Каждую неделю выходят еще новые книги.

Подпишитесь, там будут книги и марафоны задач по SQL и много редкой литературы. https://t.me/sql_lib

🧠 SQL-задача с подвохом: “Найди самого активного… по количеству разных друзей”

📘 Условие

У тебя есть таблица дружбы:

friends(user_id, friend_id)

Здесь каждая строка означает, что user_id дружит с friend_id.
Записи всегда односторонние: если есть (1, 2), это не значит, что будет (2, 1).

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

❓ Пример попытки:

SELECT user_id, COUNT(friend_id) AS total_friends
FROM friends
GROUP BY user_id
ORDER BY total_friends DESC
LIMIT 1;

🔍 Вопрос:

1) В чём здесь может быть логическая ошибка?
2) Какую строку подсчитает COUNT(friend_id)?
3) Когда нужно использовать COUNT(DISTINCT friend_id)?
4) Как обойти случай, если один и тот же друг записан несколько раз?

✅ Разбор подвоха

💣 Проблема: один пользователь может быть записан как друг **несколько раз**, особенно если приложение допускает дубли (или "перезапросы дружбы").

Пример:

```sql
INSERT INTO friends VALUES (1, 2), (1, 2), (1, 3);
```

В этом случае:

```sql
SELECT COUNT(friend_id) FROM friends WHERE user_id = 1;
-- → вернёт 3
```

Но реальных друзей у пользователя `1` — только **2**: `2` и `3`.

✅ Решение:

Используй `COUNT(DISTINCT friend_id)`:

```sql
SELECT user_id, COUNT(DISTINCT friend_id) AS unique_friends
FROM friends
GROUP BY user_id
ORDER BY unique_friends DESC
LIMIT 1;
```

🎯 Дополнительно можно убрать самого пользователя из списка друзей (на случай ошибок):

```sql
WHERE user_id != friend_id
```

⚠️ Подвох

• `COUNT()` без `DISTINCT` ловит даже опытных — особенно если в БД возможны дубли
• `LIMIT 1` не гарантирует "уникального победителя", если у нескольких одинаковый счёт
• Иногда friendship бывает и симметричной, тогда нужна защита от двойного счёта