SQL Ready | Базы Данных
Авторский канал про Базы Данных и SQL Ресурсы, гайды, задачи, шпаргалки. Информация ежедневно пополняется! Автор: @energy_c РКН: https://clck.ru/3QREBc Реклама на бирже: https://telega.in/c/sql_ready
Show more📈 Analytical overview of Telegram channel SQL Ready | Базы Данных
Channel SQL Ready | Базы Данных (@sql_ready) in the Russian language segment is an active participant. Currently, the community unites 16 628 subscribers, ranking 7 616 in the Technologies & Applications category and 39 646 in the Russia region.
📊 Audience metrics and dynamics
Since its creation on невідомо, the project has demonstrated rapid growth, gathering an audience of 16 628 subscribers.
According to the latest data from 05 September, 2026, the channel demonstrates stable activity. Although there has been a change in the number of participants by 1 264 over the last 30 days and by -1 over the last 24 hours, overall reach remains high.
- Verification status: Not verified
- Engagement rate (ER): The average audience engagement rate is 12.65%. Within the first 24 hours after publication, content typically collects 6.08% reactions from the total number of subscribers.
- Post reach: On average, each post receives 2 103 views. Within the first day, a publication typically gains 1 011 views.
- Reactions and interaction: The audience actively supports content: the average number of reactions per post is 25.
- Thematic interests: Content is focused on key topics such as sql, строка, users, индекс, user_id.
📝 Description and content policy
The author describes the resource as a platform for expressing subjective opinions:
“Авторский канал про Базы Данных и SQL
Ресурсы, гайды, задачи, шпаргалки.
Информация ежедневно пополняется!
Автор: @energy_c
РКН: https://clck.ru/3QREBc
Реклама на бирже: https://telega.in/c/sql_ready”
Thanks to the high frequency of updates (latest data received on 06 September, 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.
EXPLAIN и ANALYZE.
Предположим, у нас есть большая таблица, которая содержит около миллиона строк с разными книгами. Естественно у нас уже есть некластерный индекс по столбцу жанр — для быстрого поиска книг по жанрам, сделаем запрос:
SELECT book_title, author FROM books WHERE genre = 'Фантастика';
Но запрос возвращает результат не за 200 ожидаемых мс, а за 900 мс. Многовато, надо разбираться, проанализируем запрос:
EXPLAIN ANALYZE SELECT book_title, author FROM books WHERE genre = 'Фантастика';
Запрос EXPLAIN ANALYZE возвращает план запроса и время выполнения каждой операции в запросе:
QUERY PLAN Seq Scan on books (cost=0.00..25000.00 rows=1000 width=100) (actual time=0.010..900.000 rows=500 loops=1) Filter: (genre = 'Фантастика'::text) Rows Removed by Filter: 999500 Planning Time: 0.200 ms Execution Time: 900.500 ms (4 rows)Проанализируем план запроса и увидим, что планировщик запроса собирается обойти всю таблицу —
Seq Scan on books, хотя должен использовать индекс по жанру. Это значит, планировщик не использует индекс из-за устаревшей статистики или из-за быстрого роста записей в таблице.
🔥 В следующей части расскажу, что делать для обновления статистики таблицы и как избежать таких ситуаций с помощью VACUUM ANALYZE.
➡️ SQL Ready | #практикаЭта шпаргалка поможет понять, в каком порядке вызываются SQL операторы и как правильно писать запросы, учитывая этот порядок.
➡️ SQL Ready | #шпора• Предобработка данных перед записью в БД. • Логирование изменений - кто внес изменения, добавил или удалил строчки. • Оповещение другие модулей или сервисов при взаимодействии с таблицей. • Реализация бизнес-логики.В следующей части рассмотрим как создать исполняемую функцию для такого триггера! ➡️ SQL Ready | #гайд
SELECT * FROM users WHERE username = '$username' AND password = '$password'
Но что если юзер в поле логин решил ввести следующее:
' OR '1'='1'Тогда запрос приобретет вид:
SELECT * FROM users WHERE username = '' OR '1'='1' AND password = '$password'
И поскольку для запроса поле username остается пустым, левая часть оператора OR будет истиной, запрос вернет пользователю все учетные записи из БД, и тот сможет авторизоваться под любой из них.
Решение — использование параметризованных запросов и placeholders вида %s для PostgreSQL.
Перепишем запрос с помощью Python, но условимся, что уже подключены к БД и объекту курсора для выполнения запросов:
username = input()
password = input()
sql = "SELECT * FROM users WHERE username = %s AND password = %s;"
cur.execute(sql, (username, password)) # метод объекта курсора, выполняющий запрос
results = cur.fetchall() # возвращает все строки результата запроса
И не забудем закрыть подключение к БД и объекту курсора.
🔥 Поэтому! Используйте параметризацию данных или ORM, внимательно настраивайте валидацию этих данных и вы точно избежите утечек связанными с SQL-инъекциями.
➡️ SQL Ready | #практикаВ этой шпаргалке собраны самые важные табличные методы, которые нужны для построения запросов в таблицы
➡️ SQL Ready | #шпора