즐거운 개발자가 되자

sqld를 위한 학습 중 예제에서 발견한 exists와 in에 관련된 내용을 하나 정리하려고 한다. 예제문제 예제 중, 특정 기간 이후 발송된 총 메일의 갯수가 이벤트의 갯수 미만인 유저(이벤트 메일이 하나 이상 누락된 유저)의 정보를 표시하는 쿼리가 있었다. 테이블 구조    예제를 재현하기 위해 유저, 이벤트 정보, 메일 발송내역 테이블을 생성하고 테스트를 위한 값들을 insert해준 상태이다.  상황user_id가 1인 유저의 경우 모든 event에 대한 메시지를 받은 상태이고, 2와 3인 유저는 일부 event에 대한 message가 누락된 상태이다.   문제의 쿼리문과 결과 사진이다. 코드 블럭으로 옮겨보면SELECT a.user_id, a.user_name, a.email FROM t10_us..

Self 조인을 통해 계층을 조회하고 싶을 때 사용하는 방법과 그 안에서의 순환 참조에 대해 실험해보았다. 기본 문법   일단 테스트를 위해 계층 구조 조회가 가능한 테이블을 간단하게 만들었다. 회사의 특정 사원은 회사에 속한 EMPLOYEE임과 동시에, 누군가의 MANAGER일 수 있기 때문에 위의 사진과 같은 테이블 구조가 나타날 수 있다. 누가 누구의 manager인지를 한 번에 조회하는 기능으로 SYS_CONNECT_BY_PATH라는 기능이 있다.  우선 SELECT절을 하나씩 살펴보면LEVEL은 루트에서 해당 ROW의 레벨을 나타낸다. START WITH 절을 통해 ID를 NULL로 시작했을 때,NULL 다음에 오는 사람인 경우( 본인 상위에 매니저가 없는 사람 ) LEVEL을 1으로 표기한다...

총 인원수 중 해당 row가 몇등인지를 0부터 1사이의 값을 통해 비율로 나타내는 두 가지 방법이 있다. SQL Server(MSSQL)에서는 지원하지 않는다.  먼저, PERCENT_RANK라는 함수가 있다. 이 함수는 특정 값에 대해 ORDER BY한 후 순위를 백분위로 매겨야 할 때 매우 편리하게 사용할 수 있다.    그리고 또 한가지는 CUME_DIST라는 함수가 있다.  완전 같은 조건의 테이블에, 같은 쿼리에서 PERCENT_RANK와 CUME_DIST만 바꿨을 때 결과에서 약간의 차이가 있는 것을 확인할 수 있다. 책에 나온 설명에 따르면 PERCENT_RANK는 특정 범위 내에서 맨 윗 행을 0, 맨 아래 행을 1로 하여 각 행의 위치를 백분율로 나타낸 값이다. 맨 윗 행은 0으로 시작해..

그냥 단순히 합계를 나타내고 마는 sum()보다 조금 더 고급진? 사용법이 있어서 소개할까 한다.   쿼리로 특정 이름을 가진 분류의 값 합계 등을 조회할 때는 대부분 Group by를 사용해 나타낸다. 이런 테이블이 있다고 했을 때, dept_no별로 salary 통계를 내고 싶다면  이렇게 group by를 통해 sum해주는 게 가장 일반적인 방식이다.   다만 이 방법은 해당 dept_no 그룹 내 각 row의 emp_no나 salary를 개별 조회하는 게 불가능하다는 단점이 있다.이미 dept_no로 그룹화 해버렸기 때문이다. 그래서 해당 그룹에 어떤 emp_no가 있는지 알기 위해서는 결과를 확인한 후 추가적인 쿼리를 통해 조회해야 하는 등 불편함이 있을 수 있다.  그럴 때 유용한 것이 SUM..

SQL 기초 문제를 풀다 보면 select문에서 뭔가를 count할 때 습관적으로 애스터리스크(*)를 인자로 넣고 있는 자신을 발견할 수 있다. ex) SELECT COUNT(*) FROM USERWHERE 조건1 GROUP BY 이름; 대충 이런식이다.가끔 문제를 풀고 정답을 공유해주는 분들 중에는 COUNT에 특정 COLUMN을 명시해두는 사람도 있어서이번 기회에 둘의 차이가 뭔지 정확히 정리하고 가야 할 것 같아서 글로 적어본다.  tu.t2 테이블에 2개의 column에 대해 값이 있거나 null인 4가지 경우의 수를 row로 생성하였다.    먼저 col1을 명시해서 카운트했을 땐, 2라는 값이 나온다.count를 비롯한 집계함수는 기본적으로 null값을 제외하기 때문이다.위의 테이블을 기준으로..

SQL에서 HAVING은 특정 그룹에 대한 집계 함수에 조건을 달기 위해서 사용한다.  그래서 주로 GROUP BY와 함께 사용하는 경우가 많다. 하지만 엄연히 말하면 GROUP BY가 필수인 것은 아니고, 테이블 전체를 하나의 그룹으로 집계 조건을 달고 싶을 때는 GROUP BY 없이도 사용이 가능하다. 이렇게 되어있는 테이블 전체를 하나의 그룹으로 잡고 SUM, MAX, AVG같은 함수에 조건을 달고 싶다면  바로 적용이 가능하다.전체 합계가 2만이 넘었기 때문에 정상적으로 조회되는 것을 확인할 수 있다.   또 HAVING 조건문에서는 SUM을 달았지만 SELECT에는 다른 항목을 표시해도 무방하다.    하지만 앞서 말했듯이 테이블 전체를 하나의 그룹으로 묶어서 HAVING 조건을 달았기 때문에,..

add_months는 특정 날짜에서 지정한 개월만큼 더해주는 함수이다. 매 달은 31일 혹은 30일로 되어 있고 2월달의 경우 28, 29일이기 때문에, 단순히 month의 수를 올리기만 해서는 edge case가 발생할 것이다. 위의 사진과 같은 상황에서 그냥 단순히 Month의 숫자를 1에서 2로 바꾸면 2024-02-31 같이 존재할 수 없는 날짜가 나올 것이고, date타입이라면 오류가 발생하거나 구조에 따라 다음 달로 넘어가버리는 경우가 발생할 수 있겠다. 해서 escape를 위해 위와 같이 해당 달의 마지막 날로 자동 변환해주는 것을 알 수 있다.  편리한 기능이지만, 이로 인해 발생하는 또다른 문제가 있다. 바로 위와 반대의 경우이다.  처음에는 1월에 1달을 더한 결과로 2월 29일이 나오..

FLOOR는 '대상 값보다 작은 정수중 가장 큰 정수' 를 반환하는 내림으로 작동하고,TRUNC는 말 그대로 소숫점 뒷 자리를 없는 것처럼 만드는 차이가 있다. 이렇게, 대상 숫자가 양의 실수일때는 둘 다 똑같이 동작한다.소숫점이 달려있는 실수보다 작은 정수 중 가장 큰 수를 구하기 위해서는 소숫점을 버리면 되기 때문이다.  하지만 대상이 음의 실수라면 둘은 다른 결과를 반환한다-123.52와 같이 음의 실수에 각각 TRUNC , FLOOR를 적용하게 되면TRUNC의 경우 소숫점 자체를 잘라버려서 정수인 -123만 남게 된다. FLOOR의 경우 -123.52 보다 '작은 수 중 가장 큰 정수' 를 찾기 때문에,단순히 .52를 버리는 것이 아닌 -124를 반환하게 된다.  또 TRUNC의 경우 앞의 예제에..

기본적으로 RTRIM, LTRIM 등은 공백을 제거하는 용도로 사용한다. 추가로 ORACLE에서는 조금 더 확장된 사용법이 있다. RTRIM(문자열) : 기본 기능. 오른쪽 공백 제거RTRIM(문자열, '특정 문자') : 오른쪽에서 한 글자씩 비교하며 특정 문자일 경우 제거, 아닐 경우 멈춤. LTRIM도 동일하지만 왼쪽에서 진행하게 된다.여기서 주의할 점은 '한 글자씩 비교' 한다는 점이다. 신기해서 직접 테스트해본 결과를 사진으로 정리하겠다. 먼저 COL1에  '  cececece' 라는 값을 테스트하기 위해 넣어주었다. 앞에 공백 2칸이 존재한다.   여기에 단순히 LTRIM(대상, 조건)을 걸면, 아무일도 일어나지 않는다.왜냐면 첫 번째 칸이 ' '(공백)이기 때문이다.LTRIM(문자열) 일 경우..

일반적으로 한 개의 엔티티는 두 가지 이상의 속성을 갖는다.또 한 개의 속성이 두 개 이상의 속성값을 가지지 않도록 하는 것이 바람직하다.(제1 정규형) 속성은 더 이상 쪼개지지 않는 단위여야 한다. 고려할 점 .엔티티의 개념 상 가질 수 있는 속성이라도 업무 프로세스에 필요하지 않을 것으로 판단되는 경우 속성을 추가하지 않는 것을 있음을 고려해야 한다. ex)학생 엔티티에 '취미' 라는 속성은 엔티티의 성격 상 추가 가능한 속성일 수 있다. 하지만 업무 프로세스에서 학생의 취미를 바탕으로 어떠한 작업도 하지 않을 계획이라면, 굳이 취미라는 속성을 추가할 필요는 없다. 반대로 말하면 당장은 아니더라도 추후에 취미를 바탕으로 특정 업무(취미 기반 동아리 활동 추천 등)를 진행할 계획이 있다면 미리 추가해둘..