SQL Ready | Базы Данных
Авторский канал про Базы Данных и SQL Ресурсы, гайды, задачи, шпаргалки. Информация ежедневно пополняется! Cотрудничество: @energy_c РКН: https://clck.ru/3QREBc
نمایش بیشتر📈 تحلیل کانال تلگرام SQL Ready | Базы Данных
کانال SQL Ready | Базы Данных (@sql_ready) در بخش زبانی روسی بازیگری فعال است. در حال حاضر جامعه شامل 17 768 مشترک است و جایگاه 7 318 را در دسته فناوری و برنامهها و رتبه 37 051 را در منطقه روسيا دارد.
📊 شاخصهای مخاطب و پویایی
از زمان ایجاد در невідомо، پروژه رشد سریعی داشته و 17 768 مشترک جذب کرده است.
بر اساس آخرین دادهها در تاریخ 20 اکتبر, 2026، کانال فعالیت پایداری دارد. در ۳۰ روز گذشته تغییر اعضا برابر 730 و در ۲۴ ساعت گذشته برابر 24 بوده و همچنان دسترسی گستردهای حفظ شده است.
- وضعیت تأیید: تأیید نشده
- نرخ تعامل (ER): میانگین تعامل مخاطب 11.55% است و در ۲۴ ساعت نخست پس از انتشار، محتوا معمولاً 5.98% واکنش نسبت به کل مشترکان کسب میکند.
- دسترسی پستها: هر پست به طور میانگین 2 052 بازدید دریافت میکند. در اولین روز معمولاً 1 062 بازدید جمعآوری میشود.
- واکنشها و تعامل: مخاطبان بهطور فعال حمایت میکنند؛ میانگین واکنش به هر پست 23 است.
- علایق موضوعی: محتوا بر موضوعات کلیدی مانند sql, строка, users, индекс, user_id تمرکز دارد.
📝 توضیح و سیاست محتوایی
نویسنده این فضا را محل بیان دیدگاههای شخصی توصیف میکند:
“Авторский канал про Базы Данных и SQL
Ресурсы, гайды, задачи, шпаргалки.
Информация ежедневно пополняется!
Cотрудничество: @energy_c
РКН: https://clck.ru/3QREBc”
به لطف بهروزرسانیهای پرتکرار (آخرین داده در تاریخ 21 اکتبر, 2026)، کانال همواره بهروز و دارای دسترسی بالاست. تحلیلها نشان میدهد مخاطبان بهطور فعال با محتوا تعامل دارند و آن را به نقطه اثرگذاری مهم در دسته فناوری و برنامهها تبدیل کردهاند.
• Работа с NULL и применение логики ветвления IF-THEN-ELSE
• Дедупликация данных
• Анализ истории со Slowly Changing Dimensions
🔊 Продолжить читать можешь на Habr!➡️ SQL Ready | #статья
CAST — преобразует указанное значение в заданный тип данных. Необходимо для преобразования строковых значений в числовые, чтобы их можно было сравнить.
• CONVERT — аналогичный метод преобразования данных, но предлагает расширенный функционал для форматирования, но поддерживается не всеми СУБД.
🔥 — если узнал новое
🤝 — если уже пользовался
➡️ SQL Ready | #метод• Лайфхаки при работе с большими загрузками.
• В каком виде стоит загружать данные.
• Неочевидные советы при работе с индексами.
🔊 Продолжить читать можешь на Habr!➡️ SQL Ready | #статья
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 | #практика