Нашел лучший сайт для изучения SQL
Хороший ресурс для освоения SQL — SQL Academy!

Это интерактивная платформа с практическими заданиями от ведущих российских компаний: ВКонтакте, Альфа-Банка, Сбера и других. Здесь найдётся всё, что нужно разработчикам, аналитикам, тестировщикам и студентам, интересующимся базами данных.интересующихся студентов.

Попробовать здесь

@sqlhub

⚡️Легкий способ получать свежие обновления и следить за трендами в разработке на вашем языке. Находите свой стек и подписывайтесь:

Python: www.tgoop.com/pythonl
Linux: www.tgoop.com/linuxacademiya
Собеседования DS: www.tgoop.com/machinelearning_interview
Нерйросети www.tgoop.com/ai_machinelearning_big_data
C++ www.tgoop.com/cpluspluc
Docker: www.tgoop.com/DevopsDocker
Хакинг: www.tgoop.com/linuxkalii
Devops: www.tgoop.com/DevOPSitsec
Data Science: www.tgoop.com/data_analysis_ml
Javascript: www.tgoop.com/javascriptv
C#: www.tgoop.com/csharp_ci
Java: www.tgoop.com/javatg
Базы данных: www.tgoop.com/sqlhub
Python собеседования: www.tgoop.com/python_job_interview
Мобильная разработка: www.tgoop.com/mobdevelop
Golang: www.tgoop.com/Golang_google
React: www.tgoop.com/react_tg
Rust: www.tgoop.com/rust_code
ИИ: www.tgoop.com/vistehno
PHP: www.tgoop.com/phpshka
Android: www.tgoop.com/android_its
Frontend: www.tgoop.com/front
Big Data: www.tgoop.com/bigdatai
МАТЕМАТИКА: www.tgoop.com/data_math
Kubernets: www.tgoop.com/kubernetc
Разработка игр: https://www.tgoop.com/gamedev
Haskell: www.tgoop.com/haskell_tg
Физика: www.tgoop.com/fizmat

💼 Папка с вакансиями: www.tgoop.com/addlist/_zyy_jQ_QUsyM2Vi
Папка Go разработчика: www.tgoop.com/addlist/MUtJEeJSxeY2YTFi
Папка Python разработчика: www.tgoop.com/addlist/eEPya-HF6mkxMGIy
Папка ML: https://www.tgoop.com/addlist/2Ls-snqEeytkMDgy
Папка FRONTEND: https://www.tgoop.com/addlist/mzMMG3RPZhY2M2Iy

😆ИТ-Мемы: www.tgoop.com/memes_prog
🇬🇧Английский: www.tgoop.com/english_forprogrammers
🧠ИИ: www.tgoop.com/vistehno

🎓954ГБ ОПЕНСОРС КУРСОВ: @courses
📕Ит-книги бесплатно: https://www.tgoop.com/addlist/BkskQciUW_FhNjEy

🔍 Milvus — масштабируемая высокопроизводительная векторная БД для AI-приложений с нативной интеграцией с Kubernetes.

Проект написан на Go и C++ и оптимизирован для работы с миллиардами векторов в реальном времени. Помимо классических dense-векторов, Milvus поддерживает sparse-модели для полнотекстового поиска и гибридные запросы. Для локального тестирования есть облегченная версия, устанавливаемая через pip.

🤖 GitHub

@sqlhub

NotebookLM теперь умеет делать подкасты на русском и других славянских языках

Новая функция позволяет превращать документы в аудио — можно генерировать как полезные, так и совсем абсурдные подкасты (пример в посте). Идеально, чтобы слушать вместо чтения, например, во время пробежки.

Озвучка на русском немного уступает английской, но звучит достойно.

🎧 Бесплатно, пробуем

## 7 полезных приёмов для Oracle SQL

Простые советы для Oracle SQL, которые помогут аналитикам данных прокачать свои запросы.

1) Фильтрованные (partial) индексы
В Oracle можно создавать индексы только для подмножества строк, чтобы ускорить выборку по популярным условиям.

CREATE INDEX idx_orders_high_value
  ON orders(order_date)
  WHERE total_amount > 1000;

2) Функциональные (function-based) индексы
Если фильтруете или джойните по функции, создайте индекс прямо по выражению:

CREATE INDEX idx_orders_year
  ON orders (EXTRACT(YEAR FROM order_date));

3) GROUPING SETS, ROLLUP, CUBE
Для одновременной агрегации по нескольким группировкам без UNION ALL:

SELECT region, category, SUM(sales) AS total
FROM sales
GROUP BY ROLLUP (region, category);

4) Материализованные представления с QUERY REWRITE
В Oracle можно сделать автоматическую подмену сложного запроса предрасчитанным результатом (материализованным представлением):

CREATE MATERIALIZED VIEW mv_sales_by_month
BUILD IMMEDIATE
REFRESH FAST ON COMMIT
ENABLE QUERY REWRITE
AS
SELECT TRUNC(order_date, 'MM') AS month, SUM(total_amount) AS total
FROM orders
GROUP BY TRUNC(order_date, 'MM');

Теперь запрос SELECT month, SUM(total_amount) FROM orders GROUP BY month; автоматически будет использовать mv_sales_by_month.

5) WITH PL/SQL FUNCTION RESULT CACHE
Кэшируйте результат функции, чтобы при одинаковых входных данных не пересчитывать:

CREATE OR REPLACE FUNCTION get_tax_rate(p_region VARCHAR2)
RETURN NUMBER RESULT_CACHE RELIES_ON (tax_table) IS
  v_rate NUMBER;
BEGIN
  SELECT rate INTO v_rate FROM tax_table WHERE region = p_region;
  RETURN v_rate;
END;

6) PARALLEL HINT для ускорения запросов
Явно указывайте параллельное выполнение запроса, чтобы задействовать несколько процессов:

SELECT /*+ PARALLEL(orders, 4) */ customer_id, SUM(total_amount)
FROM orders
GROUP BY customer_id;

7) DBMS_STATS.AUTO_SAMPLE_SIZE для сбора статистики
Используйте автоматический подбор размера выборки для более точной оптимизации плана выполнения:

EXEC DBMS_STATS.GATHER_TABLE_STATS('HR', 'ORDERS', estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE);

• Совет: проверяйте планы выполнения через DBMS_XPLAN.DISPLAY_CURSOR, чтобы видеть реальные шаги запроса, а не только предполагаемые.

@sqlhub

📜 История 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-аналитиков: "Пропавшие продажи"

📖 Описание задачи

У вас есть таблица sales, где хранятся данные о продажах:

CREATE TABLE sales (
    sale_id INT PRIMARY KEY,
    sale_date DATE,
    product_id INT,
    quantity INT,
    price DECIMAL(10,2)
);

INSERT INTO sales (sale_id, sale_date, product_id, quantity, price) VALUES
(1, '2024-01-01', 101, 1, 100.00),
(2, '2024-01-02', 102, 2, 150.00),
-- ...
-- остальные данные
;

Каждый день формируется отчёт, где суммируются продажи по дням:

SELECT sale_date, SUM(quantity * price) AS total_sales
FROM sales
GROUP BY sale_date;

✅ Вчера сумма в отчёте была 1,000,000. Сегодня — 980,000, хотя новых записей не удаляли.

📝 Ваша задача:

1. Найти, какие записи "исчезли" из отчёта, если данных в таблице sales фактически не удаляли.
2. Определить, почему эти записи больше не попадают в итоговый запрос.
3. Исправить отчёт, чтобы сумма снова стала 1,000,000.

Ограничения:

- Таблица не изменилась по количеству строк.
- Никто не менял код запроса.
- sale_date, quantity, price остались без изменений.

Подсказка: возможно, дело в NULL, JOIN или неправильной агрегации.

🕵️ Что проверяет задача:

- Знание SQL-агрегации
- Понимание NULL и работы SUM
- Умение анализировать запросы «не через код», а через их результат
- Навык находить «скрытые» ошибки данных (например, sale_date стал NULL)

💡 Решение:

При проверке выяснится, что часть записей имеет `sale_date = NULL` (например, кто-то обновил поле sale_date на NULL).

Итоговый запрос:

```sql
SELECT sale_date, SUM(quantity * price) AS total_sales
FROM sales
GROUP BY sale_date;
```

не учитывает строки, где `sale_date IS NULL`, потому что GROUP BY игнорирует NULL как отдельную группу (не попадает ни в один существующий `sale_date`).

Чтобы увидеть эти записи:

```sql
SELECT sale_date, COUNT(*), SUM(quantity * price)
FROM sales
GROUP BY sale_date;
```

Для восстановления суммы нужно добавить обработку NULL, например:

```sql
SELECT COALESCE(sale_date, 'unknown') AS sale_date, SUM(quantity * price) AS total_sales
FROM sales
GROUP BY COALESCE(sale_date, 'unknown');
```

✅ Теперь сумма снова будет 1,000,000, а "пропавшие" продажи попадут в отдельную категорию unknown.

🎯 Эта задача учит:

✅ Всегда думать о данных, а не только о коде
✅ Проверять поля на NULL даже там, где их не ожидаешь
✅ Уметь объяснять ошибки «бизнес-заказчику», а не только исправлять запрос

🔥 Отличная тренировка внимательности и понимания нюансов SQL-агрегации!

@sqlhub

💫 GlueSQL — SQL-движок, превращающий любые данные в полноценную базу данных. Этот инструмент умеет выполнять JOIN между CSV и MongoDB, работать с Git как с хранилищем данных и даже запускать SQL-запросы прямо в браузере через WebAssembly.

Что отличает GlueSQL от классических СУБД?
- Поддержка schemaless-данных
- Встроенные адаптеры для 10+ форматов
- Возможность добавлять свои хранилища через реализацию двух traits на Rust

Проект активно развивается: недавно добавили поддержку транзакций в Sled-бэкенде и анонсировали облачную версию. Для теста достаточно cargo add gluesql и уже можно писать SQL-запросы к данным в памяти.

🤖 GitHub

@sqlhub

🛢️ SQL-задача с подвохом: GROUP BY и скрытая ловушка

Условие:

Есть таблица orders:

| id | customer_id | amount | status |
|-----|-------------|--------|-----------|
| 1 | 101 | 200 | completed |
| 2 | 102 | 150 | NULL |
| 3 | 101 | 300 | completed |
| 4 | 103 | NULL | completed |
| 5 | 102 | 100 | completed |
| 6 | 101 | 250 | NULL |

Задача: найти всех клиентов, у которых сумма заказов больше 500.

Ты пишешь запрос:

SELECT customer_id, SUM(amount) as total
FROM orders
GROUP BY customer_id
HAVING SUM(amount) > 500;

❓ Вопрос:
Какие клиенты вернутся? Есть ли тут подвох? Что произойдёт с заказами, где amount или status — NULL?

🔍 Подвох:

На первый взгляд запрос правильный: мы группируем по клиентам и суммируем их заказы. Но вот критичные моменты:

1️⃣ Что происходит с NULL в `amount`?

В SQL агрегатные функции (например, SUM) игнорируют NULL значения. Это значит:

- Заказ id=4 (`amount = NULL`) не участвует в суммировании.
- Заказ id=6 (`amount = 250`) участвует, потому что amount не NULL.

2️⃣ Считаем по каждому клиенту:

- customer_id=101:
- id=1: 200
- id=3: 300
- id=6: 250
Итого: 200 + 300 + 250 = 750

- customer_id=102:
- id=2: 150
- id=5: 100
Итого: 150 + 100 = 250

- customer_id=103:
- id=4: NULL (игнорируется)
Итого: 0

3️⃣ Кто попадёт в результат:

Только customer_id=101 (с суммой 750 > 500).

---

✅ Результат:

| customer_id | total |
|-------------|--------|
| 101 | 750 |

---

💥 Подвох #2:

Допустим ты случайно написал:

HAVING SUM(amount) IS NOT NULL AND SUM(amount) > 500;

Кажется логичным? А вот нет: SUM всегда возвращает 0 (не NULL), даже если у клиента нет заказов с ненулевой суммой.

➡️ Даже клиент с только NULL значениями (например, customer_id=103) получит SUM(amount) = 0, а не NULL.

Это частая ловушка:
COUNT, SUM, AVG игнорируют NULL внутри, но результат НЕ NULL (обычно 0 или NULL в зависимости от агрегата).

---

🛠 Что ещё важно:

• Если хочешь учитывать только выполненные заказы (status = 'completed'), нужно добавить:

WHERE status = 'completed'

⚠️ Не пиши условие в HAVING для фильтрации строк — лучше фильтровать через WHERE до группировки.

✅ Вывод:

- ✅ Агрегатные функции типа SUM игнорируют NULL внутри группы.
- ✅ SUM возвращает 0, даже если все значения NULL (НЕ NULL, как думают многие).
- ✅ HAVING применяется ПОСЛЕ группировки, а WHERE — ДО.
- ✅ Ошибки часто возникают, если условие на фильтр пишут в HAVING вместо WHERE.

💡 Бонус-вопрос:
Что будет, если заменить SUM(amount) на COUNT(amount) в SELECT и HAVING? И как это повлияет на клиентов с NULL значениями?

@sqlhub