Data Science. SQL hub
По всем вопросам- @workakkk @itchannels_telegram - 🔥лучшие ит-каналы @ai_machinelearning_big_data - Machine learning @pythonl - Python @pythonlbooks- python книги📚 @datascienceiot - ml книги📚 РКН: https://vk.cc/cIi9vo #VRHSZ
Show more📈 Analytical overview of Telegram channel Data Science. SQL hub
Channel Data Science. SQL hub (@sqlhub) in the Russian language segment is an active participant. Currently, the community unites 35 837 subscribers, ranking 3 816 in the Technologies & Applications category and 18 135 in the Russia region.
📊 Audience metrics and dynamics
Since its creation on невідомо, the project has demonstrated rapid growth, gathering an audience of 35 837 subscribers.
According to the latest data from 18 June, 2026, the channel demonstrates stable activity. Although there has been a change in the number of participants by -33 over the last 30 days and by 8 over the last 24 hours, overall reach remains high.
- Verification status: Not verified
- Engagement rate (ER): The average audience engagement rate is 6.81%. Within the first 24 hours after publication, content typically collects 3.98% reactions from the total number of subscribers.
- Post reach: On average, each post receives 2 442 views. Within the first day, a publication typically gains 1 425 views.
- Reactions and interaction: The audience actively supports content: the average number of reactions per post is 12.
- Thematic interests: Content is focused on key topics such as sql, индекс, postgres, index, sqlite.
📝 Description and content policy
The author describes the resource as a platform for expressing subjective opinions:
“По всем вопросам- @workakkk
@itchannels_telegram - 🔥лучшие ит-каналы
@ai_machinelearning_big_data - Machine learning
@pythonl - Python
@pythonlbooks- python книги📚
@datascienceiot - ml книги📚
РКН: https://vk.cc/cIi9vo
#VRHSZ”
Thanks to the high frequency of updates (latest data received on 19 June, 2026), the channel maintains relevance and a high level of publication reach. Analytics show that the audience actively interacts with content, making it an important point of influence in the Technologies & Applications category.
CREATE TABLE с ключевым словом TEMPORARY или TEMP перед именем таблицы:
CREATE TEMPORARY TABLE temp_table (
id INT,
name VARCHAR(50),
age INT
);
Что тут происходит:
— Инструкция CREATE TEMPORARY TABLE используется для создания временной таблицы.
— temp_table — это имя, которое присваивается временной таблице. Имя можно выбрать любое.
— Внутри круглых скобок мы определяем столбцы временной таблицы.
— В данном примере временная таблица temp_table имеет три столбца: id типа INT, name типа VARCHAR(50) и age типа INT.
— При необходимости мы можем добавить дополнительные столбцы, указав их имена и типы данных.
— Временная таблица автоматически удаляется в конце сеанса или при завершении сеанса.
⏩Или вот ещё пример.
Допустим, у нас есть большой набор данных, и мы хотим выполнить сложный анализ или вычисления на меньшей части этих данных. Для такого анализа можно создать временную таблицу, содержащую только необходимые строки и столбцы.
-- Создать временную таблицу с подмножеством данных
CREATE TEMPORARY TABLE subset_data AS
SELECT column1, column2, column3
FROM original_table
WHERE condition;
-- Анализ подмножества данных
SELECT column1, AVG(column2) AS average_value
FROM subset_data
GROUP BY column1;
-- Удалить временную таблицу
DROP TABLE subset_data;
📎 Читать подробнее
@sqlhubYAML.
https://pypi.org/project/kestra/
@sqlhubSELECT * приводит к передаче ненужных данных, увеличению использования памяти и снижению производительности запросов.
- Решение: Укажите в операторе SELECT только необходимые столбцы.
-- Пример проблемы
SELECT * FROM employees;
-- Улучшенный запрос
SELECT employee_id, first_name, last_name FROM employees;
▶️Отсутствие индексации
- Проблема: Отсутствие индексов может привести к полному сканированию таблицы и снижению производительности запросов.
- Решение: Создайте и используйте индексы для часто используемых в выражениях WHERE столбцов.
-- Создание индекса
CREATE INDEX idx_last_name ON employees(last_name);
-- Использования индекса в запросе
SELECT * FROM employees WHERE last_name = 'Smith';
▶️Чрезмерное использование подзапросов
- Проблема: Подзапросы могут работать медленнее, чем JOIN, особенно при работе с большими наборами данных.
- Решение: Используйте JOIN, когда это возможно, а подзапросы оставьте для ситуаций, в которых они более эффективны.
-- Пример проблемы (подзапрос)
SELECT department_name FROM departments WHERE department_id IN (SELECT department_id FROM employees);
-- Улучшенный запрос (JOIN)
SELECT DISTINCT d.department_name FROM departments d JOIN employees e ON d.department_id = e.department_id;
▶️Неэффективные JOIN
- Проблема: Выбор неправильного типа JOIN (например, Cartesian JOIN) или неправильное указание условий соединения может привести к неправильным результатам или замедлению запросов.
- Решение: Разберитесь в различных типах JOIN (INNER, LEFT, RIGHT, FULL) и используйте их по назначению.
-- Пример проблемы (Cartesian JOIN)
SELECT * FROM employees, departments;
-- Улучшенный запрос (INNER JOIN)
SELECT e.employee_name, d.department_name FROM employees e
INNER JOIN departments d ON e.department_id = d.department_id;
▶️Неиспользование выражений WHERE
- Проблема: Отсутствие фильтрации данных с помощью выражений WHERE может привести к запросу ненужных данных.
- Решение: Всегда включайте выражения WHERE, ограничивающие набор результатов.
-- Пример проблемы (без выражения WHERE)
SELECT * FROM orders;
-- Улучшенный запрос (с выражением WHERE)
SELECT * FROM orders WHERE order_date >= '2023-01-01';
▶️Игнорирование планов выполнения запросов
- Проблема: Игнорирование планов выполнения запросов может привести к упущенным возможностям оптимизации.
- Решение: Используйте такие инструменты, как EXPLAIN, для анализа планов выполнения и внесения необходимых оптимизаций.
-- Просмотр плана выполнения
EXPLAIN SELECT * FROM products WHERE category = 'Electronics';
▶️Отсутствие оптимизации больших наборов данных
- Проблема: Запросы, хорошо работающие с небольшими наборами данных, могут плохо работать с большими объёмами данных.
- Решение: Реализуйте такие стратегии, как пагинация, разбиение данных на разделы и оптимизация индексов для больших наборов данных.
-- реализация пагинации
SELECT * FROM products LIMIT 10 OFFSET 20;
▶️Повторяющиеся агрегации
- Проблема: Повторение одних и тех же агрегаций в нескольких частях запроса может быть неэффективным.
- Решение: Используйте CTE (Общие табличные выражения) для хранения промежуточных результатов и избегайте лишних вычислений.
-- Пример проблемы (повторяющаяся агрегация)
SELECT department, SUM(salary) AS total_salary FROM employees GROUP BY department;
-- Улучшенный запрос (с CTE)
WITH DepartmentSalaries AS (
SELECT department, SUM(salary) AS total_salary FROM employees GROUP BY department
)
SELECT * FROM DepartmentSalaries;
▶️Неадекватная обработка ошибок
- Проблема: Неправильная обработка ошибок может привести к сбоям в работе приложения или неправильным результатам.
- Решение: Реализуйте надлежащую обработку ошибок в SQL запросах или в коде приложения.
-- Пример обработки ошибок в SQL (MySQL)
BEGIN;
-- SQL выражение
IF some_condition THEN
ROLLBACK; -- Откат транзакции при ошибке
ELSE
COMMIT; -- Коммит транзакции при успешном выполнении всех выражений
END IF;
@sqlhubBEGIN, COMMIT, ROLLBACK.
⏩Транзакции выполняются внутри сессий. Сессия — это одно соединение с базой данных, которое начинается при подключении к базе данных и завершается при её отключении. Транзакция начинается с команды BEGIN и завершается командой COMMIT (успешное завершение) или ROLLBACK (откат). Указывать BEGIN, COMMIT и ROLLBACK не обязательно, часто их использование подразумевается неявно. В случае если сессия неожиданно прерывается, тогда все транзакции, которые были начаты в текущей сесcии – автоматически откатываются.
⏩Подробнее:
— BEGIN – инициирует новую транзакцию. После выполнения этой команды все последующие операции с базой данных будут выполняться в рамках этой транзакции.
— COMMIT – завершает текущую транзакцию, применяя все её операции. Если все операции в транзакции были успешными, результаты этих операций фиксируются (становятся постоянными). Изменения становятся видны последующим транзакциям.
— ROLLBACK – откатывает текущую транзакцию, отменяя все её операции, если в процессе выполнения транзакции возникли ошибки или отмена транзакции производится приложением исходя из внутренней логики работы.
⏩Если данные, внесённые с помощью транзакции на изображении верны – нужно выполнить инструкцию подтверждения транзакции:
COMMIT;
📎 Читать подробнее
@sqlhubcursor.execute("SELECT * FROM my_table WHERE id = ?", [123])
# parameter placeholder ------------------------> ^
# список/кортеж со значениями параметров -----------> ^^^^^
⏩Какие преимущества приносит использование параметров?
— Защита от SQL-инъекций
— Правильное квотирование литералов в зависимости от их типа (пример со строками, пример с датами).
— Оптимизация — сокращение времени работы SQL запроса. Благодаря использованию параметров следующие шаги не выполняются при повторном запуске (зависит от БД):
— проверка синтаксиса SQL запроса
— проверка прав доступа к объектам БД
— построение плана выполнения SQL запроса
— Защита от переполнения/вытеснения кеша SQL запросов. Например "безобидный" запрос qry = f"SELECT first_name, last_name FROM users WHERE id = {user_id}", который часто выполняется в нагруженной системе с различными значениями user_id может вытеснить из кеша запросов полезные запросы.
⏩ Пример использования параметров в SQL запросе:
import sqlite3
con = sqlite3.connect(":memory:")
cur = con.cursor()
cur.execute("create table lang (name, first_appeared)")
cur.execute("insert into lang values (?, ?)", ("C", 1972))
lang_list = [
("Fortran", 1957),
("Python", 1991),
("Go", 2009),
]
cur.executemany("insert into lang values (?, ?)", lang_list)
cur.execute("select * from lang where first_appeared=:year", {"year": 1972})
print(cur.fetchall())
con.close()
При таком подходе можно использовать cursor.executemany() - это значительно быстрее и эффективнее по сравнению с вставкой в цикле по одной строке.
📎 Читать подробнее
@sqlhubJOIN, IN, LIKE, BETWEEN, ORDER BY, а также много всего ещё
Пользуйтесь)
@sqlhubconcurrently control. При том, не только в БД, а везде где хоть что-то выполняется параллельно.
Допустим есть пользователь, у него есть 100 денег на счету. Пользователь может их тратить, вы проверяете баланс SELECT balance ..., затем обновляете баланс при покупке UPDATE ... SET balance = ? WHERE .... И вот в счастливый день как-то так вышло, что приходят сразу 2 запроса на покупки для этого пользователя. Одна на 50 денег, вторая на 70. Одна из них должна быть отклонена, т.к. денег недостаточно. Но в результате получается что обе покупки прошли и у вас проблема, вы продали то, что не надо было. И это даже не видно по балансу пользователя. Как же?
Это типичный race condition, обе транзакции сначала данные читают, потом локально что-то делают, потом что-то пишут.
⏩читать им никто не мешает, потому обе транзакции прочитали что у пользователя 100 денег
⏩обе транзакции закономерно решили что денег достаточно
⏩обе транзакции обновили баланс пользователя
При конкурентном доступе к ресурсу подрались только на последнем шаге, транзакция которая начала обновлять данные позже сначала подождала завершение первой транзакции. А затем банально перезаписала баланс на тот который считала правильным сама — lost update аномалия.
▶️Вот как раз для того чтобы предупредить СУБД о том, что мы планируем с данными что-то делать, а потому нам надо сериализовать транзакции иначе, и существует FOR SHARE, FOR UPDATE дополнения. Потому они кстати и задокументированы в разделе Explicit Locking
📎 Подробнее прочитать можно тут
@sqlhub
Available now! Telegram Research 2025 — the year's key insights 
