저번 글(링크)에서 밝혔듯이 나는 좀 더 편하다는 이유로 조인 대신 서브 쿼리를 써왔다. 효율성을 버렸다는 것을 깨달은 후부터는 조인을 사용하고 있지만, 이런 일이 발생한 이유가 SQL 쿼리 작성의 미숙함에서 나왔다는 것을 알게 됐다.
그래서 주말을 기념해서 해커 랭크에서 SQL 문제를 풀고 있는데, 아직 easy 문제를 풀고 있어서 그런지 쉬워도 너무 쉽다. 6개의 subdomain이 있으니 다 풀고 leetcode에서 알고리즘 문제를 더 연습하면 어느정도 감을 잡을 것 같다.
문제 링크: https://www.hackerrank.com/domains/sql?filters%5Bsubdomains%5D%5B%5D=select
CITY TABLE
SELECT * FROM CITY WHERE POPULATION > 100000 AND COUNTRYCODE = 'USA'
SELECT NAME FROM CITY WHERE POPULATION > 120000 AND COUNTRYCODE = 'USA'
SELECT * FROM CITY
SELECT * FROM CITY WHERE ID = 1661
SELECT * FROM CITY WHERE COUNTRYCODE='JPN'
SELECT NAME FROM CITY WHERE COUNTRYCODE='JPN'
STATION TABLE
-- DISTINCT, % 사용 가능
SELECT DISTINCT CITY FROM STATION WHERE ID%2 = 0
-- COUNT, DISTINCT
SELECT COUNT(CITY) - COUNT(DISTINCT CITY) FROM STATION
SELECT MIN(LENGTH(CITY)) AND MAX(LENGTH(CITY)) FROM STATION ORDER BY DESC
-- SELECT 문 끝나고 ; 붙이기
-- ASC 오름차 순, DESC 내림차 순
-- ORDER BY 조건 여러개 가능
SELECT CITY, LENGTH(CITY) FROM STATION ORDER BY LENGTH(CITY) ASC, CITY ASC LIMIT 1;
SELECT CITY, LENGTH(CITY) FROM STATION ORDER BY LENGTH(CITY) DESC LIMIT 1;
-- STRING 시작
-- regular expression 사용 가능!
SELECT DISTINCT city FROM STATION WHERE CITY REGEXP "^[aeiou].*";
-- n 글자 제한해서 왼쪽, 오른쪽 부터 체크 가능!
SELECT DISTINCT(CITY) FROM STATION WHERE RIGHT(CITY, 1) IN ('a', 'e', 'i', 'o', 'u')
SELECT DISTINCT(CITY) FROM STATION WHERE (RIGHT(CITY, 1) IN ('a', 'e', 'i', 'o', 'u'))
AND (LEFT(CITY, 1) IN ('a', 'e', 'i', 'o', 'u'))
SELECT DISTINCT CITY FROM STATION WHERE LEFT(CITY, 1) NOT IN ('a', 'e', 'i', 'o', 'u')
SELECT DISTINCT CITY FROM STATION WHERE RIGHT(CITY, 1) NOT IN ('a', 'e', 'i', 'o', 'u')
SELECT DISTINCT(CITY) FROM STATION WHERE (RIGHT(CITY, 1) NOT IN ('a', 'e', 'i', 'o', 'u'))
OR (LEFT(CITY, 1) NOT IN ('a', 'e', 'i', 'o', 'u'))
여기서는 조금 당황했다. 마치 난이도가 갑자기 0에서 1로 오른 느낌🤨?
STUDENTS, EMPLOYEE TABLE
SELECT NAME FROM STUDENTS WHERE MARKS > 75 ORDER BY RIGHT(NAME, 3), ID
SELECT NAME FROM EMPLOYEE ORDER BY ASC
SELECT NAME FROM EMPLOYEE WHERE SALARY > 2000 AND MONTHS < 10 ORDER BY EMPLOYEE_ID ASC
그나저나 이렇게 SQL 문제를 풀고 있으니 문득 떠오른다. 현대의 복잡한 소프트웨어 시스템에서 데이터베이스는 사용되지 않을 수가 없다. 그러니 소프트웨어 개발자가 데이터를 효율적으로 읽고, 쓰는 방법을 알아야 한다는 것은 명제나 다름없다.
데브옵스도 마찬가지다. 데브옵스가 왜 시작됐는지를 생각해보면, 데브옵스는 직군이라기보단 문화다. 애초에 개발팀이 서비스 개발에만 집중하고, 운영팀은 보안과 인프라에만 집중해서 빈번한 배포에 유연하게 대처하지 못하게 되어 데브옵스가 생긴 거다. 그러니 어디에 더 전문성을 가지고 있는지의 정도는 다르겠지만, 개발자라면 역시 자신만의 도메인을 가져야 하지 않을까 생각했다.
'Database' 카테고리의 다른 글
[MySQL/HackerRank]Basic Join, Advanced Select 上 (0) | 2021.05.15 |
---|---|
[MySQL/HackerRank]Aggregation (0) | 2021.05.15 |
[SQL] Join vs Sub-query, sharding (0) | 2021.04.09 |
2021년 4월 DBMS 인기 순위 (0) | 2021.04.03 |
[MongoDB]파이썬에서 MongoDB 사용하기 (0) | 2021.03.25 |