Влияние индекса на фильтрацию в SQL при хорошей селективности.
Покажу на примере как в случае частой фильтрации по одному и тому же полю в SQL запросе существенное влияние на ускорение выполнения влияет создание индекса.
Конечно индекс может быть не всегда полезен, но в случае хорошей селективности значений, ускорение может стать пушкой.
Сейчас мы с вами в этом убедимся. Взгляните на скриншоты, где я проводил эксперимент. Думаю все станет однозначно понятно.
Покажу на примере как в случае частой фильтрации по одному и тому же полю в SQL запросе существенное влияние на ускорение выполнения влияет создание индекса.
Конечно индекс может быть не всегда полезен, но в случае хорошей селективности значений, ускорение может стать пушкой.
Сейчас мы с вами в этом убедимся. Взгляните на скриншоты, где я проводил эксперимент. Думаю все станет однозначно понятно.
👍4
Друзья, всем привет. Не вдаваясь в подробности что означает данный запрос какая на ваш взгляд версия более читабельнее и понятнее для вас?
Применение
Конструкция
Но многие не догадываются о всех ее способностях и местах применения в различных частях запроса. Вот например, как вы думаете можно ли создать категории конструкцией
Представим что нам необходимо создать три категории заказов по весу:
Ну что ж, посмотрим на это. Оказывается что можно.
CASE в различных частях SQL запроса.Конструкция
CASE это невероятно крутая штука, которая способна закрыть множество задач, связанных с выполнением условных операций. Но многие не догадываются о всех ее способностях и местах применения в различных частях запроса. Вот например, как вы думаете можно ли создать категории конструкцией
CASE в операторе SELECT и в этом же запросе отфильтровать по созданной категории?Представим что нам необходимо создать три категории заказов по весу:
'тяжелый', 'средний', 'легкий' и вывести в результате только 'тяжелый'. Ну что ж, посмотрим на это. Оказывается что можно.
❤5👀1
С днем программиста, друзья!
В России День программиста отмечается 13 сентября. Этот праздник был установлен в 2009 году по инициативе Ассоциации программистов России.
Число 13 выбрано в честь 256-го числа, которое является наибольшей степенью числа 2, меньшей 365 (количество дней в году).
256 также символизирует количество различных значений, которые можно представить с помощью 8-битного байта.
В России День программиста отмечается 13 сентября. Этот праздник был установлен в 2009 году по инициативе Ассоциации программистов России.
Число 13 выбрано в честь 256-го числа, которое является наибольшей степенью числа 2, меньшей 365 (количество дней в году).
256 также символизирует количество различных значений, которые можно представить с помощью 8-битного байта.
👍2🔥2👏2
INNER JOIN в SQL.
Представьте что у нас есть две таблицы table_1 с полем A и table_2 c полем В, и в каждом поле по три строки с значениями 1. Вопрос: Сколько строк с значением 1 получится в результате INNER JOIN?
Представьте что у нас есть две таблицы table_1 с полем A и table_2 c полем В, и в каждом поле по три строки с значениями 1. Вопрос: Сколько строк с значением 1 получится в результате INNER JOIN?
Anonymous Quiz
50%
3
19%
6
31%
9
0%
12
Оптимизация
Представьте что нам нужно найти все рекламные источники, начинающиеся на букву
На скриншотах вы можете увидеть что второй вариант работает шустрее.
LIKE в конкретной задаче SQL.Представьте что нам нужно найти все рекламные источники, начинающиеся на букву
'v'. Первое что придет в голову использовать оператор LIKE. SELECT *Запрос отработает как надо. Но конкретно в этом примере запрос можно было написать оптимальнее т.к.
FROM events e
WHERE ad_channel LIKE 'v%'
LIKE тяжеловат для СУБД. Посмотрим как можно было изменить запрос:SELECT *Здесь мы использовали функцию
FROM events e
WHERE LEFT (ad_channel, 1) = 'v'
LEFT, при помощи которой достали только первую букву источника и сравнили ее с 'v'.На скриншотах вы можете увидеть что второй вариант работает шустрее.
👍6
Что такое базы данных NoSQL и какие у них преимущества?
NoSQL (или "нереляционные базы данных") представляет собой подход к управлению данными, который отличается от традиционных реляционных баз данных, таких как PostgreSQL. В то время как реляционные базы данных используют таблицы, столбцы и связи для организации данных, NoSQL базы данных используют другие модели данных, такие как ключ-значение, документы, столбцы или графы.
NoSQL базы данных часто используются в приложениях, где требуется гибкая схема данных или быстрый доступ к большим объемам данных, таким как социальные сети, интернет-магазины, аналитические приложения и т.д.
В отличие от PostgreSQL, NoSQL базы данных обычно не поддерживают SQL-запросы и транзакции в том же виде. Тогда как осуществляется доступ к информации?
Например, в базах данных типа ключ-значение, данные доступны по ключу, в документ-ориентированных базах данных, данные хранятся в виде документов и доступ осуществляется через идентификаторы документов и их поля.
Кроме того, NoSQL базы данных обычно предлагают более гибкую схему данных, что означает, что поля и структура данных могут быть изменены без необходимости изменения схемы базы данных. В реляционных базах данных изменение схемы может быть сложным и требовать пересоздания таблиц, что может быть затруднительно при работе с постоянно меняющимися данными.
В целом, NoSQL базы данных предназначены для работы с разнородными, распределенными и масштабируемыми данными, обладают высокой производительностью и гибкостью, но требуют от разработчиков изменения подхода к моделированию данных и выполнению запросов.
NoSQL (или "нереляционные базы данных") представляет собой подход к управлению данными, который отличается от традиционных реляционных баз данных, таких как PostgreSQL. В то время как реляционные базы данных используют таблицы, столбцы и связи для организации данных, NoSQL базы данных используют другие модели данных, такие как ключ-значение, документы, столбцы или графы.
NoSQL базы данных часто используются в приложениях, где требуется гибкая схема данных или быстрый доступ к большим объемам данных, таким как социальные сети, интернет-магазины, аналитические приложения и т.д.
В отличие от PostgreSQL, NoSQL базы данных обычно не поддерживают SQL-запросы и транзакции в том же виде. Тогда как осуществляется доступ к информации?
Например, в базах данных типа ключ-значение, данные доступны по ключу, в документ-ориентированных базах данных, данные хранятся в виде документов и доступ осуществляется через идентификаторы документов и их поля.
Кроме того, NoSQL базы данных обычно предлагают более гибкую схему данных, что означает, что поля и структура данных могут быть изменены без необходимости изменения схемы базы данных. В реляционных базах данных изменение схемы может быть сложным и требовать пересоздания таблиц, что может быть затруднительно при работе с постоянно меняющимися данными.
В целом, NoSQL базы данных предназначены для работы с разнородными, распределенными и масштабируемыми данными, обладают высокой производительностью и гибкостью, но требуют от разработчиков изменения подхода к моделированию данных и выполнению запросов.
👍3
4 преимущества использования колоночных СУБД. Для чего они применяются и в чем их слабость.
Колоночная СУБД — это тип системы управления базами данных, в котором данные хранятся и организованы по колонкам, а не по строкам, как в традиционных реляционных СУБД. Колоночные СУБД имеют ряд преимуществ и применяются для решения определенных задач:
1. Эффективность при аналитических запросах: Колоночные СУБД предназначены для обработки аналитических запросов, которые часто требуют агрегации и анализа больших объемов данных. Такая организация данных по колонкам позволяет быстро извлекать и анализировать только необходимые колонки, минимизируя объем данных для чтения и ускоряя выполнение запросов.
2. Компрессия данных: Колоночные СУБД часто применяют сжатие данных, что позволяет уменьшить объем занимаемого пространства на диске. Это особенно важно при работе с большими объемами данных, где эффективное использование дискового пространства может существенно сэкономить ресурсы хранения.
3. Параллельная обработка: Колоночная организация данных позволяет эффективно распараллелить выполнение запросов и операций агрегации. Каждая колонка может обрабатываться независимо, что увеличивает производительность и позволяет быстро обрабатывать большие объемы данных.
4. Оптимизация для чтения: Колоночные СУБД оптимизированы для операций чтения данных, так как они активно используются в аналитических работах и поисковых запросах, где скорость извлечения данных является критическим фактором.
Колоночные СУБД наиболее часто применяются для аналитических и отчетных задач, где нужно обрабатывать большие объемы данных и проводить сложные агрегации и анализы. Прирост скорости выполнения запросов может достигать 10-ти кратных величин. Только не подумайте теперь, а зачем нам тогда реляционная СУБД=).
У колоночных СУБД есть и недостатки. Они медленно работаю работают на запись данных, не подходят для транзакционных систем и т д.
Колоночная СУБД — это тип системы управления базами данных, в котором данные хранятся и организованы по колонкам, а не по строкам, как в традиционных реляционных СУБД. Колоночные СУБД имеют ряд преимуществ и применяются для решения определенных задач:
1. Эффективность при аналитических запросах: Колоночные СУБД предназначены для обработки аналитических запросов, которые часто требуют агрегации и анализа больших объемов данных. Такая организация данных по колонкам позволяет быстро извлекать и анализировать только необходимые колонки, минимизируя объем данных для чтения и ускоряя выполнение запросов.
2. Компрессия данных: Колоночные СУБД часто применяют сжатие данных, что позволяет уменьшить объем занимаемого пространства на диске. Это особенно важно при работе с большими объемами данных, где эффективное использование дискового пространства может существенно сэкономить ресурсы хранения.
3. Параллельная обработка: Колоночная организация данных позволяет эффективно распараллелить выполнение запросов и операций агрегации. Каждая колонка может обрабатываться независимо, что увеличивает производительность и позволяет быстро обрабатывать большие объемы данных.
4. Оптимизация для чтения: Колоночные СУБД оптимизированы для операций чтения данных, так как они активно используются в аналитических работах и поисковых запросах, где скорость извлечения данных является критическим фактором.
Колоночные СУБД наиболее часто применяются для аналитических и отчетных задач, где нужно обрабатывать большие объемы данных и проводить сложные агрегации и анализы. Прирост скорости выполнения запросов может достигать 10-ти кратных величин. Только не подумайте теперь, а зачем нам тогда реляционная СУБД=).
У колоночных СУБД есть и недостатки. Они медленно работаю работают на запись данных, не подходят для транзакционных систем и т д.
👏4
Как в PostgreSQL посчитать разницу в часах между двумя полями с типами timestamp?
Допустим у нас есть дата – время взятия продукта в аренду и дата – время возврата продукта. Наша задача посчитать разницу в часах, то есть столько продукт находился в аренде.
В примере на скриншоте два варианта:
В первом при помощи функции
Во втором варианте еще проще, вычитаем из одной даты другую, а при помощи конструкции
Этими же способами можно искать значения не только в часах, достаточно только правильно поделить чтобы конвертировать в тот временной отрезок, который вам необходим.
Допустим у нас есть дата – время взятия продукта в аренду и дата – время возврата продукта. Наша задача посчитать разницу в часах, то есть столько продукт находился в аренде.
В примере на скриншоте два варианта:
В первом при помощи функции
AGE мы находим разницу между датами в типе INTERVAL, далее при помощи конструкции EPOCH и функции EXTRACT вычисляем данную разницу в секундах, делим на 3600 и получаем искомые часы.Во втором варианте еще проще, вычитаем из одной даты другую, а при помощи конструкции
EPOCH и функции EXTRACT вычисляем данную разницу также в секундах.Этими же способами можно искать значения не только в часах, достаточно только правильно поделить чтобы конвертировать в тот временной отрезок, который вам необходим.
👍5
Партиционирование в SQL.
Партиционирование в базах данных - это процесс разделения большой таблицы на более мелкие фрагменты, называемые партициями, чтобы улучшить производительность и управление данными. Каждая партиция хранится отдельно и может иметь свою собственную структуру индексов и хранение на диске.
Партиционирование может быть полезно в следующих случаях:
1. Управление объемом данных: Если таблица содержит большое количество записей, партиционирование может помочь управлять этим объемом данных. Запросы могут выполняться более эффективно на отдельных партициях, и операции обслуживания данных могут быть более быстрыми и менее нагруженными.
2. Улучшение производительности: Партиционирование может ускорить выполнение запросов, разделяя данные между различными физическими дисками или массивами хранения. Это позволяет параллельно обрабатывать запросы на разных партициях, улучшая производительность системы в целом.
3. Облегчение обслуживания: Предоставляет возможность выполнения административных задач, таких как создание индексов и резервное копирование, на отдельных партициях, а не на всей таблице. Это может сильно сократить время, затраченное на эти операции.
SQL-синтаксис для создания партиций и управления ими может различаться в зависимости от конкретной реализации базы данных. Различные базы данных имеют свои собственные подходы к этому процессу.
Партиционирование в базах данных - это процесс разделения большой таблицы на более мелкие фрагменты, называемые партициями, чтобы улучшить производительность и управление данными. Каждая партиция хранится отдельно и может иметь свою собственную структуру индексов и хранение на диске.
Партиционирование может быть полезно в следующих случаях:
1. Управление объемом данных: Если таблица содержит большое количество записей, партиционирование может помочь управлять этим объемом данных. Запросы могут выполняться более эффективно на отдельных партициях, и операции обслуживания данных могут быть более быстрыми и менее нагруженными.
2. Улучшение производительности: Партиционирование может ускорить выполнение запросов, разделяя данные между различными физическими дисками или массивами хранения. Это позволяет параллельно обрабатывать запросы на разных партициях, улучшая производительность системы в целом.
3. Облегчение обслуживания: Предоставляет возможность выполнения административных задач, таких как создание индексов и резервное копирование, на отдельных партициях, а не на всей таблице. Это может сильно сократить время, затраченное на эти операции.
SQL-синтаксис для создания партиций и управления ими может различаться в зависимости от конкретной реализации базы данных. Различные базы данных имеют свои собственные подходы к этому процессу.
👍7👏1
Какой оконной функции ранжирования не существует ?
Anonymous Quiz
6%
ROW_NUMBER
6%
RANK
6%
DENSE_RANK
47%
NTILE
35%
Существуют все перечисленные функции
👍2
Привет всем! Давно не виделись — у меня был большой перерыв, но я возвращаюсь и рад снова делиться с вами полезными и интересными материалами. За это время было много новых идей и опыта, которыми хочу с вами поделиться, а также поделиться о своем новом проекте, который надеюсь совсем скоро будет запущен, и в котором каждый сможет принять участие. Спасибо, что остаетесь на связи, ваши поддержка и интерес для меня очень важны! Скоро начнется новый виток полезного контента, оставайтесь с нами!
❤7
LEFT JOIN кажется простым: «возьми всё из левой таблицы и добавь, что найдётся справа».
Но на деле — это один из самых коварных операторов SQL 😈
⚠️ 1. COUNT(*) считает лишнее
После LEFT JOIN даже записи без совпадений получают строку с NULL.
COUNT(*) считает и их — поэтому результат оказывается завышенным.
➡️ Решение:
используй COUNT(правая_таблица.id), чтобы считать только реальные совпадения.
❌ 2. Условия в WHERE ломают LEFT JOIN
Добавил фильтр в WHERE, например:
WHERE orders.status = 'active'
И всё — твой LEFT JOIN превратился в INNER JOIN.
Пользователи без заказов пропали из результата.
➡️ Решение:
перенеси фильтр в ON:
LEFT JOIN orders o ON u.id = o.user_id AND o.status = 'active'
🕵️♂️ 3. NULL — не всегда «ничего»
После LEFT JOIN поля из правой таблицы могут стать NULL.
Если потом сравниваешь =, !=, или фильтруешь WHERE column IS NOT NULL — результат может быть неожиданным.
➡️ Решение:
используй COALESCE() или явно проверяй IS NULL / IS NOT NULL.
⚙️ 4. LEFT JOIN трёх и более таблиц
Когда соединяешь несколько таблиц подряд можно легко потерять контроль, по какой именно таблице ты делаешь подсчёт.
Например, COUNT(payments.id) будет считать только оплаченные заказы, а COUNT(orders.id) — всех, у кого вообще есть заказы.
➡️ Решение:
будь внимателен при группировке — всегда считай по нужной таблице
и чётко понимай, на каком уровне детализации формируется результат.
Далее подробно будем разбирать каждый из моментов.
Но на деле — это один из самых коварных операторов SQL 😈
⚠️ 1. COUNT(*) считает лишнее
После LEFT JOIN даже записи без совпадений получают строку с NULL.
COUNT(*) считает и их — поэтому результат оказывается завышенным.
➡️ Решение:
используй COUNT(правая_таблица.id), чтобы считать только реальные совпадения.
❌ 2. Условия в WHERE ломают LEFT JOIN
Добавил фильтр в WHERE, например:
WHERE orders.status = 'active'
И всё — твой LEFT JOIN превратился в INNER JOIN.
Пользователи без заказов пропали из результата.
➡️ Решение:
перенеси фильтр в ON:
LEFT JOIN orders o ON u.id = o.user_id AND o.status = 'active'
🕵️♂️ 3. NULL — не всегда «ничего»
После LEFT JOIN поля из правой таблицы могут стать NULL.
Если потом сравниваешь =, !=, или фильтруешь WHERE column IS NOT NULL — результат может быть неожиданным.
➡️ Решение:
используй COALESCE() или явно проверяй IS NULL / IS NOT NULL.
⚙️ 4. LEFT JOIN трёх и более таблиц
Когда соединяешь несколько таблиц подряд можно легко потерять контроль, по какой именно таблице ты делаешь подсчёт.
Например, COUNT(payments.id) будет считать только оплаченные заказы, а COUNT(orders.id) — всех, у кого вообще есть заказы.
➡️ Решение:
будь внимателен при группировке — всегда считай по нужной таблице
и чётко понимай, на каком уровне детализации формируется результат.
Далее подробно будем разбирать каждый из моментов.
❤5👍1