SQL Ready | Базы Данных

👍 Еще одна интересная статья попалась мне на Хабре — подборка прикладных задач для аналитики данных В этой статье: • Работа с NULL и применение логики ветвления IF-THEN-ELSE • Дедупликация данных • Анализ истории со Slowly Changing Dimensions

🔊 Продолжить читать можешь на Habr!

➡️ SQL Ready | #статья

Знали про StrataScratch? Это платформа по типу leetcode, но только для SQL На этом сайте вы сможете выбрать задачи разного уровня и профиля, а также выбрать подходящую СУБД для практики. 📌 Ссылочка: stratascratch.com ➡️ SQL Ready | #ресурс

🖥 Разберем два похожих метода для работы с разными типами данных Как мы помним из викторины, чтобы не столкнуться с неожиданным результатом запроса, важно явно указать типы данных при взаимодействии разных типов. Для этого существуют методы: • CAST — преобразует указанное значение в заданный тип данных. Необходимо для преобразования строковых значений в числовые, чтобы их можно было сравнить. • CONVERT — аналогичный метод преобразования данных, но предлагает расширенный функционал для форматирования, но поддерживается не всеми СУБД. 🔥 — если узнал новое 🤝 — если уже пользовался ➡️ SQL Ready | #метод

«Вместо философии учил java, вместо доты — питон. Через 3 месяца нашёл работу с зп 90к» Думаете, повезло? Уверен, что так сможет каждый — потому что эти языки востребованы (70% программ и сервисов работают на них) и просты в усвоении (за 3 месяца можно выйти на достойный уровень без напряга). А вот и каналы, где нашёл всю инфу. Её грамотно собрали, даже сложные темы изучаются легко: Java (теория) Java (практика) Python Уже через месяц сможете писать простеньких ботов для телеги и продавать по 5-7к, кайф же 🥰

😎 Нашел для вас незаконно полезную статью на Хабре, в которой автор делится своим опытом и хитростями в работе с БД и SQL. В этой статье: • Лайфхаки при работе с большими загрузками. • В каком виде стоит загружать данные. • Неочевидные советы при работе с индексами.

🔊 Продолжить читать можешь на Habr!

➡️ SQL Ready | #статья

📥 7539 ГБ платного контента из онлайн-школ утекли в Telegram и теперь лежат в открытом доступе: 😡 Hacking & InfoSec (644 ГБ) 🖥 Python (724 ГБ) 🖥 Frontend (981 ГБ) 🖥 Backend (817 ГБ) 🖥 Все направления (4373 ГБ) Вход открыт ровно на 48 часов 🕔

Почему неожиданно увеличилось время запроса? Причин тому может быть много - неоптимизированный запрос, запрос вне индекса, устаревшая статистика таблицы и так далее. И точно определить причину помогут инструменты 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 | #практика

Верстаешь? Оцени 7 причин пройти наш бесплатный интенсив по Frontend-разработке: 1. Ты сверстаешь веб-сайт на HTML + CSS; 2. Оживишь страницу с помощью JavaScript; 3. Используешь фронтенд-фреймворк Angular; 4. Подключишь Backend и загрузишь сайт на хостинг; 5. Получишь советы по доработке от эксперта; 6. Научишься использовать ChatGPT и Giga во Frontend-разработке; 7. Узнаешь 9 способов найти первый заказ даже без опыта. А главное, ты проведёшь 7 дней в приятной компании Fullstack-разработчика с 10-летним стажем – Романа Чернова. 👉 Проскочить на интенсив бесплатно Начинаем уже завтра. 🔥 С нас обучение, практика и помощь с выходом на фриланс или собеседованием.

Exercism — это платформа для изучения программирования через практические задания. Можно практиковаться на 70 различных языках, в том числе и на SQL. 📌 Ссылочка: exercism.org ➡️ SQL Ready | #ресурс

🖥 Держите хорошую напоминалку с порядком работы операторов в запросе! Эта шпаргалка поможет понять, в каком порядке вызываются SQL операторы и как правильно писать запросы, учитывая этот порядок. ➡️ SQL Ready | #шпора

Подборка популярных каналов по информационной безопасности и этичному хакингу: 🔐 infosec — ламповое сообщество, которое публикует редкую литературу, курсы и полезный контент для ИБ специалистов любого уровня и направления. 😈 Social Engineering — самый крупный ресурс в Telegram, посвященный этичному Хакингу, OSINT и социальной инженерии. 💬 Вакансии в ИБ — актуальные предложения от самых крупных работодателей и лидеров рынка в сфере информационной безопасности.

Как отследить, кто внес изменения в вашу таблицу? Поговорим про снифферы трафика триггеры в SQL: При внесении изменений в таблицу триггеры автоматически запускают выполнение разного рода и назначения функции. Рассмотрим, какие бывают типы триггеров и для каких событий. В основном их используют для:

• Предобработка данных перед записью в БД. • Логирование изменений - кто внес изменения, добавил или удалил строчки. • Оповещение другие модулей или сервисов при взаимодействии с таблицей. • Реализация бизнес-логики.

В следующей части рассмотрим как создать исполняемую функцию для такого триггера! ➡️ SQL Ready | #гайд

Если надоело читать разные каналы по программированию, то вот вам хороший канал Это канал с новостями программирования, который стоит читать ежедневно 📌 Ссылочка: @umnyiprogrammist

Как защитить свои запросы от SQL-инъекций? Если вы используете данные, введенные пользователем, напрямую в SQL запросах, вы рискуете дать доступ к вашей БД вредоносному коду. Разберем, как НЕ нужно писать запросы, и какая практика обезопасит вас от SQL Injection. Например, для авторизации пользователя проверяем его существование в нашей БД:

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 | #практика