it_skills_ua

Приклад використання індексів в SQL

Індекс - це обʼєкт, для підвищення ефективності запитів під час фільтрації даних.

Перш ніж подивитися для цікавості, пропоную пройти цей тест по SQL

Максимальна якість на ютуб каналі

#sql_code

Навігація по телеграм каналу
👇👇👇

Задачі по SQL коду:
#sql_code

Різна інформація щодо IT:
#about_it

Різна інформація щодо SQL:
#about_sql

Інформація про мої курси:
#about_courses

Інтерв'ю з моїми студентами:
#true_stories

IT меми:
#memes

IT меми з моєю участю:
#memes_from_it_skills_ua

Всі мої соцмережі
👇👇👇

1. Instagram it_skills_ua
2. Instagram особиста
3. Telegram SQL Chat
4. Tik Tok
5. YouTube
6. Сайт
7. linkedin it_skills_ua
8. linkedin особистий

«Тест-драйв SQL» можна стартувати в будь-який день після оплати 149 грн, це один практичний урок з домашкою, яку я перевіряю.

«Тест-драйв SQL» це урок який розкриває теми для новачків в SQL і найголовніше в рамках «Тест-драйв SQL» ви зможете зрозуміти мій формат навчання та мою подачу, де питання задавати при необхідності і так далі. Це дуже важливо якщо в майбутньому захочете придбати якийсь мій професійний курс по SQL.

Придбати «Тест-драйв SQL», можна у мене на сайті:
ПРИДБАТИ

#about_courses

Проста SQL задача:
Отримати суму продажів за 10 жовтня 2017 року з таблиці slp_chequelines

Є такий аналіз по цій таблиці:
1. В таблиці 38 мільйонів рядків;
2. Даних в таблиці за пів року;
3. По полю період (поле dat, тип даних DATE) побудований індекс;

Питання:
Який із цих варіантів фільтрації буде найоптимальніший по часу виконання?:

-- Варіант №1
SELECT sum(pricein)
FROM supermarket.slp_chequelines
WHERE trunc(dat) = to_date('10.10.2017', 'DD.MM.YYYY');

-- Варіант №2
SELECT sum(pricein)
FROM supermarket.slp_chequelines
WHERE dat >= to_date('10.10.2017', 'DD.MM.YYYY')
AND dat < to_date('11.10.2017', 'DD.MM.YYYY');

-- Варіант №3
SELECT sum(pricein)
FROM supermarket.slp_chequelines
WHERE to_char(dat, 'DD.MM.YYYY') = '10.10.2017';

Готую для вас відео розбір цієї ситуації.

Опитування на цю тему нижче👇, також якщо є думки "Який варіант краще і чого?", цікаво почути ваші думки в коментарях опитування.

#sql_code

Пошукав для вас вакансії на посаду PL-SQL Developer. Ось три найцікавіші на мій погляд:

1. PL-SQL Developer (помітка - бронювання)
2. SQL Developer
3. Trainee PL-SQL Developer (помітка - перша робота)

Про софт скіли та як підвищувати свою ЗП

Якщо ви хочете рости по заробітній платі, знаходячи достойні офери в ІТ, я вам рекомендую подивитися безкоштовне відео Павла, де він по поличкам розклав:
«Як стабільно отримувати нові офери і рости в зп в 2025 році»

Щоб отримати його безкоштовне відео про техніки отримання ІТ оферів, переходьте на інстаграм сторінку Павла та пишіть йому в дірект, слово «софти».

#about_it

Завжди знайдуться ті, кому не сподобається мій контент. Але експериментувати треба я вважаю.

Сьогодні хочу в інстаграмі запустити на це відео рекламу і спробувати зібрати ще більше підписників які цікавляться SQL.

А вам цим відео, просто хочу підняти настрій😁

#memes #memes_from_it_skills_ua

Всім гарної пʼятниці та вихідних.

Це для розуміння мему👇

1. Pull request – запит на внесення змін у спільний код проекту, який ініціює перевірку цих змін іншими учасниками.
2. Бібліотека в програмуванні – набір готових функцій або класів, які спрощують розробку, забезпечуючи повторне використання коду.
3. Код-рев’ю – процес перевірки нового коду колегою для виявлення помилок, покращення якості та забезпечення відповідності стандартам.
4. Техлід – технічний лідер команди, який відповідає за технічну сторону проекту та керує роботою розробників.
5. Апрувити pull request – схвалити запропоновані зміни в коді, що дозволяє їх інтеграцію у проект.
6. Due date задачі – крайній термін виконання певного завдання, коли його потрібно завершити.

#memes

ПриватБанк в пошуках PL/SQL Developer.

Посилання на їх вакансію:

https://jobs.dou.ua/companies/privatbank/vacancies/277056/

SQL задача:
Знайти всіх співробітників, які зараз працюють на тих самих посадах і в тих самих департаментах, на яких коли-небудь працював співробітник із employee_id = 101.

-- Рішення №1:
SELECT e.first_name, e.last_name, e.job_id, e.department_id
FROM employees e
INNER JOIN job_history j
ON (e.job_id = j.job_id AND e.department_id = j.department_id)
WHERE j.employee_id = 101;

-- Рішення №2:
SELECT e.first_name, e.last_name, e.job_id, e.department_id
FROM employees e
WHERE (e.job_id, e.department_id) IN (SELECT j.job_id, j.department_id
                                      FROM job_history j
                                      WHERE j.employee_id = 101);

Перший запит використовує JOIN, тоді як другий запит досягає, того ж самого результату через оператор IN з двома полями.

#sql_code

Запис прямого ефіру: "SQL це ключова навичка IT спеціалістів" на моєму ютуб каналі:

https://youtube.com/live/o-hBmcZy26A

#about_sql

SQL задача з розбором UNION vs UNION ALL+DISTINCT

Аналізуємо план виконання запитів, щоб визначити, яка конструкція є більш оптимальною за часом виконання.

Максимальна якість на ютуб каналі

#sql_сode

Друзі вчіть SQL😉😃

Всім гарної пʼятниці та вихідних✌️

#memes

SQL задача: "Підрахувати кількість унікальних продуктів на основі двох таблиць".

Рішення №1:

SELECT COUNT(lagerid)
FROM (SELECT lagerid
      FROM slp_saleskiev2017
      UNION
      SELECT lagerid
      FROM slp_saleskiev2016);

Рішення №2:

SELECT COUNT(DISTINCT lagerid)
FROM (SELECT lagerid
      FROM slp_saleskiev2017
      UNION ALL
      SELECT lagerid
      FROM slp_saleskiev2016);

Через тиждень запишу відео, де детально розберу цю ситуацію: проаналізуємо план виконання запитів і з'ясуємо, яке із рішень є оптимальніше в плані ресурсів до БД та яке рішення працює швидше на великих обʼємах даних.

#sql_code

Розбираємо міф в SQL, коли кажуть, що з'єднання таблиць за допомогою синтаксису "INNER JOIN" є більш продуктивним, ніж старий синтаксис з'єднання таблиць "через кому у FROM".

Максимальна якість на ютуб каналі

#sql_сode

Вакансія!

Я працюю зараз на аутсорсингу на Київстар, і у нас на проєкті потрібен ще один тестувальник зі знання Oracle PL-SQL, або хоча б просто зі знаннями SQL, який готовий вивчити PL-SQL на випробовальному терміні.

Головна мета, щоб тестувальник в підсумку писав автотести на PL-SQL і в Postman колекції для тестування API.

Якщо це ви, або у вас є кого порекомендувати, перешліть мені резюме і я перекину його своєму менеджеру для розглядання.

Існує такий міф в SQL, що з'єднання таблиць за допомогою синтаксису "INNER JOIN" є більш продуктивним, ніж старий синтаксис з'єднання таблиць "через кому у FROM".

Через тиждень запишу відео, де детально розберу цю ситуацію: проаналізуємо план виконання запитів і з'ясуємо, це міф або правда.

-- з'єднання таблиць "через INNER JOIN":
SELECT e.first_name, e.last_name, d.department_name
FROM employees e
INNER JOIN departments d
ON e.department_id = d.department_id;

-- з'єднання таблиць "через кому у FROM":
SELECT e.first_name, e.last_name, d.department_name
FROM employees e, departments d
WHERE e.department_id = d.department_id;

Пишіть в коментарях, свої думки на рахунок цього міфу👇

#sql_code

Змінив авку в телеграм каналі. Не губіть мене✌️