🤔 데이터, 그냥 쌓기만 하면 될까?

JOIN으로 데이터를 합치는 법을 배우고 나니, 문득 이런 생각이 들었다
‘데이터가 정확하지 않다면, 이 모든 게 무슨 소용이지?’

오늘은 데이터의 신뢰성을 지키는 규칙인 제약조건(Constraints)부터
검색 속도를 빠르게 만드는 인덱스(Index)
복잡한 쿼리를 단순화하는 뷰(View)
그리고 데이터 분석의 새로운 눈을 뜨게 해준 윈도우 함수(Window Functions)까지

데이터를 더 깊이 이해하고, 더 똑똑하게 다루는 법을 고민해보았다


⛓️ 제약조건: 데이터의 규칙을 세우다

제약조건은 데이터베이스 스스로가 데이터의 무결성을 지키도록 만드는 규칙이었다
잘못된 데이터가 들어오는 것을 시스템 차원에서 막아주니
훨씬 안정적인 데이터 관리가 가능해질 것이라 생각했다

제약조건 나의 다짐과 생각
PRIMARY KEY 각 데이터를 유일하게 구별해주는 신분증, 절대 중복되거나 비어있으면 안 된다고 다짐했다
FOREIGN KEY 테이블들을 연결해주는 끈, 이 관계 덕분에 데이터의 일관성을 유지할 수 있음을 깨달았다
UNIQUE 중복은 안되지만 NULL은 허용하는 유연함, 이메일처럼 고유해야 하지만 필수 입력이 아닐 때 유용해 보였다
NOT NULL ‘이 값은 반드시 입력해야 해!’ 라고 강제하는 중요한 약속
CHECK 데이터가 특정 조건(예: 나이는 0 이상)에 맞는지 검사하는 똑똑한 문지기
DEFAULT 깜빡하고 값을 넣지 않아도 기본값을 채워주는 친절함

⚡ 인덱스: 필요한 정보를 빠르게 찾는 기술

데이터가 수백만 건이라면 원하는 것을 어떻게 찾을까
인덱스는 책의 ‘찾아보기’처럼, 데이터의 주소를 기억해두어
검색 속도를 극적으로 향상시키는 기술이었다

PRIMARY KEYUNIQUE를 걸면 자동으로 인덱스가 생긴다는 점이 흥미로웠다
하지만, 무분별한 인덱스는 오히려 데이터 변경 시 성능을 저하시킬 수 있다는 점을 명심해야겠다고 생각했다
꼭 필요한 곳에, 신중하게 사용해야겠다


🎭 뷰: 복잡한 세상을 단순하게 보는 창

여러 테이블을 조인한 복잡한 쿼리를 매번 다시 쓰는 건 비효율적이었다
뷰(View) 는 이 복잡한 쿼리를 하나의 가상 테이블로 저장해두는 기능이었다

실제 데이터는 없지만, 있는 것처럼 행동하는 뷰 덕분에
쿼리는 단순해지고, 보안상 숨기고 싶은 데이터를 감추는 효과도 얻을 수 있었다
자주 사용하는 쿼리를 뷰로 만들어두는 습관을 들여야겠다


윈도우 함수: 데이터 분석의 새로운 지평

Subquery로 순위를 매기고, 그룹별 집계를 하던 과정은 꽤나 복잡했다
하지만 윈도우 함수를 만나고 모든 것이 달라졌다

OVER()를 통해 데이터를 분할하고(PARTITION BY), 정렬해서(ORDER BY)
순위(RANK, DENSE_RANK), 누적 합계(SUM), 이전/이후 값(LAG, LEAD) 등을
너무나도 간결하게 계산할 수 있었다

특히 부서별로 순위를 매기는 코드를 짤 때, 그 편의성을 체감했다

-- 부서별로 급여 순위를 매겨보자
SELECT
    ename,
    sal,
    RANK() OVER (PARTITION BY deptno ORDER BY sal DESC) AS sal_rank
FROM emp;

이 강력한 도구를 어떻게 활용할 수 있을지 고민하는 것만으로도 즐거웠다


✨ 오늘의 회고

오늘은 단순히 SQL 문법을 배우는 것을 넘어
데이터의 신뢰성, 성능, 편의성, 그리고 분석의 깊이까지 고민하는 시간이었다

제약조건으로 데이터의 규칙을 세우고
인덱스로 성능을 개선하며
뷰로 복잡함을 감추고
윈도우 함수로 데이터의 숨겨진 의미를 찾는 과정

이 모든 것이 좋은 데이터를 다루는 개발자의 기본 소양임을 깨달았다
앞으로는 쿼리 하나를 작성하더라도, 이 네 가지를 항상 염두에 두려 노력해야겠다 🚀