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
Сегодня, у нас небольшое пополнение. Ребята из группы решили присоединиться. Спасибо. В этой группе скоро станет невероятно интересно, пока вы даже не понимаете насколько.
❤7👍1
Также хочу попросить всех ребят не стесняться делиться ссылкой на канал с друзьями.
Хотите еще новость. Сегодня я сдал высший уровень владения PostgreSQL.
🔥8
По просьбе ребят, подготовил краткую шпаргалку.
🧭 Как не забыть SQL после курса ?
1. Практикуйся каждый день
SQL — это навык, который держится на регулярности.
10–20 минут в день уже дают результат.
Используй тренажёры, например:
SQLZoo
LeetCode SQL
Hackerrank SQL
2. Повторяй материал курса
Пересматривай видеолекции: даже знакомые темы открываются по-новому.
Перечитывай конспекты и примеры — замечай, что стало понятнее.
Перерешивай задания: попробуй сделать старые задачи без подсказок — это лучший способ увидеть прогресс.
3. Веди “SQL-дневник”
После каждой практики запиши коротко:
Что повторил или узнал
Что вызвало трудности
Один полезный приём или запрос
Так создашь личную базу знаний и мотивации.
4. Повторяй темы циклично
Раз в неделю пробегай ключевые блоки:
SELECT → JOIN → GROUP BY → подзапросы → оконные функции
Постоянное повторение — основа уверенности.
5. Применяй SQL в жизни
Придумай мини-проект: анализ фильмов, покупок, чтения книг или расходов.
Главное — использовать SQL на реальных данных, пусть даже небольших.
Регулярность важнее длительности. Главное — не прекращать.
🧭 Как не забыть SQL после курса ?
1. Практикуйся каждый день
SQL — это навык, который держится на регулярности.
10–20 минут в день уже дают результат.
Используй тренажёры, например:
SQLZoo
LeetCode SQL
Hackerrank SQL
2. Повторяй материал курса
Пересматривай видеолекции: даже знакомые темы открываются по-новому.
Перечитывай конспекты и примеры — замечай, что стало понятнее.
Перерешивай задания: попробуй сделать старые задачи без подсказок — это лучший способ увидеть прогресс.
3. Веди “SQL-дневник”
После каждой практики запиши коротко:
Что повторил или узнал
Что вызвало трудности
Один полезный приём или запрос
Так создашь личную базу знаний и мотивации.
4. Повторяй темы циклично
Раз в неделю пробегай ключевые блоки:
SELECT → JOIN → GROUP BY → подзапросы → оконные функции
Постоянное повторение — основа уверенности.
5. Применяй SQL в жизни
Придумай мини-проект: анализ фильмов, покупок, чтения книг или расходов.
Главное — использовать SQL на реальных данных, пусть даже небольших.
Регулярность важнее длительности. Главное — не прекращать.
❤4
💬 Стоит ли использовать ИИ в работе и обучении?
Меня часто спрашивают:
можно ли вообще использовать ИИ для работы или обучения?
Отвечаю — можно и нужно.
Но важно — делать это с головой.
ИИ реально помогает: ускоряет задачи, подкидывает идеи, помогает учиться.
Но есть нюанс — он не несёт ответственности.
Ошибся не ИИ, а ты. Спрашивать будут с нас.
Недавно я ради эксперимента попросил ИИ написать несколько достаточно сложных SQL-запросов.
Результат выглядел идеально — синтаксис, логика, всё красиво.
Но при проверке оказалось, что ответ неверный.
И вот в этом опасность: если ты не разбираешься в теме, можно просто не заметить ошибку.
ИИ — не костыль. Это инструмент для роста.
Он может помочь понять больше, но не подменяет мышление.
И чем лучше ты сам разбираешься в теме, тем сильнее эффект от его использования.
И вот еще один важный интересный момент:
ИИ ведь учится у людей, учится на данных, на тех же к нему запросах (промтах).
Если человек со временем перестанет думать, разбираться и учиться — то и ИИ станет глупее.
Мы фактически учим его своим мышлением.
Так что, чтобы ИИ развивался, умнеть должны мы сами.
Поэтому ИИ не должен «разучивать» нас — наоборот, он должен мотивировать учиться ещё больше, чтобы использовать его максимально эффективно.
ИИ — не замена эксперту.
Он — ускоритель эксперта 🚀
Меня часто спрашивают:
можно ли вообще использовать ИИ для работы или обучения?
Отвечаю — можно и нужно.
Но важно — делать это с головой.
ИИ реально помогает: ускоряет задачи, подкидывает идеи, помогает учиться.
Но есть нюанс — он не несёт ответственности.
Ошибся не ИИ, а ты. Спрашивать будут с нас.
Недавно я ради эксперимента попросил ИИ написать несколько достаточно сложных SQL-запросов.
Результат выглядел идеально — синтаксис, логика, всё красиво.
Но при проверке оказалось, что ответ неверный.
И вот в этом опасность: если ты не разбираешься в теме, можно просто не заметить ошибку.
ИИ — не костыль. Это инструмент для роста.
Он может помочь понять больше, но не подменяет мышление.
И чем лучше ты сам разбираешься в теме, тем сильнее эффект от его использования.
И вот еще один важный интересный момент:
ИИ ведь учится у людей, учится на данных, на тех же к нему запросах (промтах).
Если человек со временем перестанет думать, разбираться и учиться — то и ИИ станет глупее.
Мы фактически учим его своим мышлением.
Так что, чтобы ИИ развивался, умнеть должны мы сами.
Поэтому ИИ не должен «разучивать» нас — наоборот, он должен мотивировать учиться ещё больше, чтобы использовать его максимально эффективно.
ИИ — не замена эксперту.
Он — ускоритель эксперта 🚀
👍3
🎓 7 строковых функций в PostgreSQL, которые стоит знать каждому аналитику.
🔹
Используются, чтобы привести строки к одному формату перед сравнением.
🔹
Но будь внимателен ⚠️: CONCAT() игнорирует NULL,
а || вернёт NULL, если хотя бы один аргумент NULL.
🔹
Укажи строку, символ-разделитель и номер части, которую хочешь получить.
🔹
Работает по позиции и длине: “начало” и “сколько символов”.
🔹
Когда нужно взять только начало строки.
🔹
Помогает достать “хвост” строки — например, окончание кода или номера.
🔹
1. LOWER / UPPER — меняют регистр текстаИспользуются, чтобы привести строки к одному формату перед сравнением.
SELECT
LOWER('PostgreSQL'), -- postgresqlUPPER('sql rocks'); -- SQL ROCKS🔹
2. CONCAT и || — объединяют строкиНо будь внимателен ⚠️: CONCAT() игнорирует NULL,
а || вернёт NULL, если хотя бы один аргумент NULL.
SELECT
CONCAT('Ivan', ' ', 'Petrov'), -- Ivan PetrovCONCAT('Ivan', ' ', NULL), -- Ivan'Ivan' || ' ' || 'Petrov', -- Ivan Petrov'Ivan' || ' ' || NULL; -- NULL ⚠️🔹
3. SPLIT_PART — разделяет строку по разделителюУкажи строку, символ-разделитель и номер части, которую хочешь получить.
SELECT
SPLIT_PART('ivan.petrov@example.com', '@', 1), -- ivan.petrovSPLIT_PART('ivan.petrov@example.com', '@', 2); -- example.com🔹
4. SUBSTRING — достаёт часть строкиРаботает по позиции и длине: “начало” и “сколько символов”.
SELECT
SUBSTRING('2025-10-21' FROM 1 FOR 4), -- 2025SUBSTRING('Analytics' FROM 4 FOR 3); -- lyt🔹
5. LEFT — возвращает первые n символовКогда нужно взять только начало строки.
SELECT
LEFT('PostgreSQL', 4); -- Post🔹
6. RIGHT — возвращает последние n символовПомогает достать “хвост” строки — например, окончание кода или номера.
SELECT
RIGHT('PostgreSQL', 3); -- SQL👍4