Mockaroo — это онлайн-инструмент для генерации фейковых данных в различных форматах (JSON, CSV, SQL и др.), идеально подходящий для тестирования приложений и прототипирования.

⛓ Ссылочка: mockaroo.com

➡️ SQL Ready | #ресурс

Как защитить свои запросы от 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 | #практика

Exercism — это платформа для изучения программирования через практические задания. Можно практиковаться на 70 различных языках, в том числе и на SQL.

📌 Ссылочка: exercism.org

➡️ 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.

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

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

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