PostgreSQL 주니어 코딩 면접
새 면접Q. PostgreSQL에서 특정 조건을 만족하는 행만 집계하고 싶을 때 사용할 수 있는 FILTER 절의 사용 방법을 설명하고, CASE WHEN을 사용한 조건부 집계와 비교했을 때의 장단점을 설명해주세요.
FILTER 절은 집계 함수 뒤에 FILTER (WHERE 조건)을 붙여 특정 조건을 만족하는 행만 집계할 수 있습니다. 예를 들어 COUNT(*) FILTER (WHERE status = 'active')처럼 사용합니다. CASE WHEN을 사용하면 SUM(CASE WHEN status = 'active' THEN 1 ELSE 0 END)처럼 작성해야 하는데, FILTER 절이 더 간결하고 가독성이 좋습니다. FILTER는 SQL 표준이며 의도가 명확하지만, CASE WHEN은 더 복잡한 조건 처리가 가능하다는 장점이 있습니다. 성능은 대부분의 경우 비슷하지만 FILTER가 옵티마이저에게 더 명확한 힌트를 제공합니다.
- • FILTER (WHERE 조건) 구문으로 조건부 집계 수행
- • CASE WHEN보다 간결하고 가독성이 우수함
- • SQL 표준이며 옵티마이저에게 명확한 의도 전달
여러 개의 조건부 집계를 동시에 수행해야 할 때, FILTER 절을 어떻게 활용할 수 있을까요?
Q. PostgreSQL에서 문자열 검색을 할 때 LIKE, ILIKE, SIMILAR TO의 차이점을 설명하고, 각각 어떤 상황에서 사용하는 것이 적절한가요?
LIKE는 대소문자를 구분하는 패턴 매칭으로 %와 _ 와일드카드를 사용합니다. ILIKE는 LIKE와 동일하지만 대소문자를 구분하지 않는 PostgreSQL 전용 확장 기능입니다. SIMILAR TO는 SQL 표준 정규표현식을 사용하여 더 복잡한 패턴을 표현할 수 있습니다. 간단한 부분 문자열 검색에는 LIKE를 사용하고, 대소문자 무관한 검색에는 ILIKE를 사용하며, 복잡한 패턴이 필요한 경우 SIMILAR TO나 정규표현식 연산자를 사용합니다. 성능을 고려할 때는 인덱스 활용 가능 여부도 중요합니다.
- • LIKE는 대소문자 구분, ILIKE는 대소문자 무시
- • SIMILAR TO는 SQL 표준 정규표현식 지원
- • 패턴 복잡도와 성능 요구사항에 따라 선택
LIKE 연산자를 사용할 때 인덱스를 효과적으로 활용하려면 어떤 점을 고려해야 하나요?
Q. PostgreSQL에서 데이터 타입을 변환하는 방법인 CAST 함수와 :: 연산자의 차이점을 설명하고, 암시적 타입 변환(Implicit Casting)과 명시적 타입 변환(Explicit Casting)의 차이를 예시와 함께 설명해주세요.
CAST(value AS type)와 value::type은 기능적으로 동일하며 명시적 타입 변환을 수행합니다. CAST는 SQL 표준이고 ::는 PostgreSQL 전용 단축 표기법으로 더 간결합니다. 암시적 타입 변환은 PostgreSQL이 자동으로 수행하는 변환으로 integer를 numeric으로 변환하는 경우가 대표적입니다. 명시적 타입 변환은 개발자가 직접 지정하는 것으로 text를 integer로 변환할 때 필요합니다. 암시적 변환은 편리하지만 예상치 못한 결과를 초래할 수 있어, 중요한 변환은 명시적으로 수행하는 것이 안전합니다.
- • CAST 함수는 SQL 표준, ::는 PostgreSQL 단축 표기법
- • 암시적 변환은 자동, 명시적 변환은 개발자가 직접 지정
- • 명시적 변환이 의도를 명확히 하고 안전함
타입 변환 시 발생할 수 있는 오류를 안전하게 처리하려면 어떤 방법을 사용할 수 있나요?
Q. PostgreSQL에서 일반 뷰(View)와 구체화된 뷰(Materialized View)의 차이점을 설명하고, 구체화된 뷰를 사용해야 하는 상황과 데이터를 갱신하는 방법을 설명해주세요.
일반 뷰는 저장된 쿼리로 실행할 때마다 실제 테이블에서 데이터를 조회하는 가상 테이블입니다. 구체화된 뷰는 쿼리 결과를 물리적으로 저장하여 조회 성능을 향상시키지만 실시간 데이터를 반영하지 않습니다. 복잡한 집계나 조인이 필요하고 데이터가 자주 변경되지 않는 경우 구체화된 뷰가 적합합니다. REFRESH MATERIALIZED VIEW 명령으로 데이터를 갱신하며, CONCURRENTLY 옵션을 사용하면 조회를 차단하지 않고 갱신할 수 있습니다. 실시간성과 성능 사이의 트레이드오프를 고려하여 선택해야 합니다.
- • 일반 뷰는 가상 테이블, 구체화된 뷰는 물리적 저장
- • 구체화된 뷰는 복잡한 쿼리의 성능 향상에 유용
- • REFRESH MATERIALIZED VIEW로 데이터 갱신
구체화된 뷰에 인덱스를 생성할 수 있나요? 생성할 수 있다면 어떤 이점이 있나요?
Q. PostgreSQL에서 CHECK 제약조건의 역할을 설명하고, 테이블 레벨 CHECK와 컬럼 레벨 CHECK의 차이점, 그리고 CHECK 제약조건으로 구현할 수 있는 실무 예시를 제시해주세요.
CHECK 제약조건은 컬럼 값이 특정 조건을 만족하는지 검증하여 데이터 무결성을 보장합니다. 컬럼 레벨 CHECK는 단일 컬럼에 대한 제약으로 컬럼 정의 시 함께 작성하고, 테이블 레벨 CHECK는 여러 컬럼 간의 관계를 검증할 수 있습니다. 예를 들어 나이는 0 이상이어야 한다는 CHECK (age >= 0), 시작일은 종료일보다 빨라야 한다는 CHECK (start_date < end_date), 할인율은 0에서 100 사이여야 한다는 CHECK (discount_rate BETWEEN 0 AND 100) 등을 구현할 수 있습니다. 애플리케이션 레벨 검증과 함께 사용하면 더 강력한 데이터 보호가 가능합니다.
- • CHECK 제약조건은 컬럼 값의 유효성 검증
- • 컬럼 레벨은 단일 컬럼, 테이블 레벨은 여러 컬럼 간 관계 검증
- • 데이터베이스 레벨에서 데이터 무결성 보장
CHECK 제약조건에서 서브쿼리나 사용자 정의 함수를 사용할 수 있나요? 제한사항이 있다면 무엇인가요?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!