📜 История 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 бывает и симметричной, тогда нужна защита от двойного счёта

🔥 Polars: шпаргалка

Polars ≠ Pandas. Это колоночный движок, вдохновлённый Rust и SQL. Никаких SettingWithCopyWarning — всё иммутабельно и параллелится.

🚀 Быстрый старт

import polars as pl

df = pl.DataFrame({
    "id": [1, 2, 3],
    "name": ["Alice", "Bob", "Charlie"],
    "score": [95, 85, 100]
})

📊 Выборка и фильтрация

df.filter(pl.col("score") > 90)
df.select(pl.col("name").str.lengths())
df[df["id"] == 2]

• Комбинированные условия:

df.filter((pl.col("score") > 80) & (pl.col("name").str.contains("A")))

---

## ⚙️ Трансформации

• Вычисление новых колонок:

df.with_columns([
    (pl.col("score") / 100).alias("percent"),
    pl.col("name").str.to_uppercase().alias("name_upper")
])

• Удаление/переименование:

df.drop("id").rename({"name": "username"})

• apply() — только если нельзя обойтись иначе:

df.with_columns(
    pl.col("score").map_elements(lambda x: x * 2).alias("doubled")
)

🧠 Группировка и агрегаты

df.groupby("name").agg([
    pl.col("score").mean().alias("avg_score"),
    pl.count()
])

• Агрегация с кастомной функцией:

df.groupby("name").agg(
    (pl.col("score") ** 2).mean().sqrt().alias("rms")
)

---

## 🪄 Ленивая обработка (LazyFrame)

lf = df.lazy()
result = (
    lf
    .filter(pl.col("score") > 90)
    .with_columns(pl.col("score").log().alias("log_score"))
    .sort("log_score", descending=True)
    .collect()
)

✅ Всё оптимизируется *до выполнения* — pushdown, predicate folding, projection pruning.

🔥 Joins

df1.join(df2, on="id", how="inner")

Варианты: "inner", "left", "outer", "cross", "semi", "anti"

📂 Работа с файлами

pl.read_csv("data.csv")
df.write_parquet("out.parquet")
pl.read_json("file.json", json_lines=True)

Ленивая загрузка:

pl.read_parquet("big.parquet", use_pyarrow=True).lazy()

---

## 🧮 Аналитика и окна

df.with_columns([
    pl.col("score").rank("dense").over("group").alias("rank"),
    pl.col("score").mean().over("group").alias("group_avg")
])

🧱 Структуры, списки, explode

df = pl.DataFrame({
    "id": [1, 2],
    "tags": [["a", "b"], ["c"]]
})
df.explode("tags")

• Работа с вложенными списками:

df.select(pl.col("tags").list.lengths())

🧪 Полезные фичи

• Проверка типов:

df.schema
df.dtypes

• Проверка на null:

df.filter(pl.col("score").is_null())

• Заполнение:

df.fill_null("forward")

• Выбор n лучших:

df.sort("score", descending=True).head(5)

📦 Советы и best practices

• Используй lazy() для производительности.

• Избегай .apply() — если можешь, используй pl.col().map_elements() или векторные выражения.

• Сохраняй schema — удобно при пайплайнах данных.

• @pl.api.register_expr_namespace("yourns") — добавляй кастомные методы как namespace.


✅ Polars: минимализм, скорость, безопасность.