Данные — это масло нового тысячелетия. К счастью для нас, программистов, для извлечения данных требуется не установка огромных буровых установок и наем высокооплачиваемых специалистов, а использование всего нескольких технологических инструментов и правильных навыков, которые можно приобрести на практике.

Большинство гигантских ИТ-систем, таких как банки, здравоохранение и больницы, имеют огромные данные и используют реляционные базы данных для своих повседневных операций. Любой, кто работает с реляционными базами данных, обязательно выберет SQL в качестве первого инструмента для извлечения данных из этих баз данных, прежде чем перейти к удобному извлечению данных. функции, предлагаемые дорогими системами анализа данных.

Родившийся в 1945 году, бумер SQL по-прежнему считается одним из 5 лучших навыков в области науки о данных в мире миллениалов 2019 года. Опытный аналитик SQL сегодня может зарабатывать до 1000 долларов в день, тем не менее, SQL легко понять, и почти все обученные программисты время от времени погружаются в него.

Хотя такие пословицы, как «никогда не используйте select *» и «используйте group by везде, где это возможно», не являются чем-то необычным, следующие интуитивно понятные, но относительно недокументированные советы пригодятся для написания быстрых и масштабируемых запросов время от времени.

Оператор Case , удобный инструмент для группировки данных

Использование операторов CASE в запросе — хороший способ сгруппировать данные в простом удобочитаемом запросе. Следующий запрос представляет собой удобный способ найти общие коммерческие расходы для каждого сезона с помощью запроса кейса.

SELECT SUM(CASE WHEN season = ‘Winter’ THEN total_cost end) as Winter_total,
SUM(CASE WHEN season = ‘Summer’ THEN total_cost end) as Summer_total,
SUM(CASE WHEN season = ‘Spring’ THEN total_cost end) as Spring_total,
SUM(CASE WHEN season = ‘Fall’ THEN total_cost end) as Spring_total,
SUM(CASE WHEN season = ‘All Year’ THEN total_cost end) as Spring_total
FROM (
select season, sum(supply * cost_per_unit) total_cost
from fruit_imports
group by season
 ) a

СОЮЗ вместо ИЛИ

Использование ИЛИ для выбора столбцов в SQL-запросе оказывается неэффективным, так как этот запрос не использует индексы таблиц и требует много времени для выполнения. Использование UNION для объединения результатов двух операторов select использует индексы и сокращает время выборки запроса.

SELECT * FROM TABLE WHERE COLUMN_1 = 'value' OR COLUMN_2 = 'value'

С другой стороны, следующий запрос выполняется быстрее.

SELECT * FROM TABLE WHERE COLUMN_1 = 'value'

UNION

SELECT * FROM TABLE WHERE COLUMN_2 = 'value'

Коррелированные подзапросы

Часто операторы SQL пытаются найти ответы на распространенные вопросы по английскому языку. «Не могли бы вы узнать, какие отделы получали доход выше среднего?» «Заработал ли какой-либо отдел в этом году даже меньше минимального дохода?

Эти вопросы кажутся прогулкой по парку, когда мы их читаем, но обращение к SQL — это еще одна игра с мячом.

Начнем с простого запроса, чтобы найти сотрудников с зарплатой выше средней.

Приведенный ниже SQL использует подзапрос, чтобы разбить проблемы на две части, во-первых, запрос, который выбирает имя и зарплату сотрудников, а второй выбирает группу сотрудников, где зарплата больше, чем средняя зарплата сотрудников. . Этот способ написания запроса не только приближает его к английскому языку, но и намного быстрее, чем использование объединений для построения SQL-запроса для таблиц среднего размера.

SELECT Name,Salary FROM Employees WHERE Salary > (Select(AVG(Salary)FROM Employees

А теперь новый запрос, где мы ищем отделы, в которых работает более 40 сотрудников.

SELECT department FROM employees WHERE 40 < (select (count(emp_id) from employees e WHERE e.department = d.department Group by department

Разве это не отличный способ написания запроса? Написание подзапросов помогает разбить проблему на более короткие блоки и сделать запросы читабельными, хотя нужно помнить, что в обоих приведенных выше примерах запрос выполняется для каждой записи в базе данных и может не подходить для огромных блоков данных.

Надеюсь, что это минутное чтение дало вам некоторое представление о том, как лучше писать SQL-запросы. Запомните этот конфетный код и дайте мне знать, если у вас есть какие-либо предложения по улучшению SQL-запросов.