SQL 뷰

GitLab에서 PostgreSQL 시스템 카탈로그에 대한 추상화 레이어로 SQL 뷰를 활용하는 방법과 장단점, 가이드라인, 테스트 방법을 설명합니다.

개요 # GitLab에서는 PostgreSQL 시스템 카탈로그( pg_* 테이블)에 대한 추상화 레이어로 SQL 뷰를 사용합니다. 이를 통해 Rails에서 시스템 카탈로그를 더 쉽게 쿼리할 수 있습니다. 예시 # 예를 들어, SQL 뷰 postgres_sequences 는 pg_sequence 및 기타 pg_* 테이블에 대한 추상화 레이어입니다. 다음 Rails 모델을 사용하여 쿼리합니다: module Gitlab module Database # Backed by the postgres_sequences view class PostgresSequence < SharedModel self.primary_key = :seq_name scope :by_table_name, ->(table_name) { where(table_name: table_name) } scope :by_col_name, ->(col_name) { where(col_name: col_name) } end end end 이를 통해 Ruby 코드로 데이터베이스 유지보수 작업을 관리할 수 있습니다: Gitlab::Database::PostgresSequence.by_table_name('web_hook_logs') => # 장점 # 이러한 뷰를 사용하면 다음과 같은 여러 이점이 있습니다: ActiveRecord 통합 : 복잡한 PostgreSQL 메타데이터 쿼리를 친숙한 ActiveRecord 모델로 래핑합니다. 유지보수 자동화 : Ruby 코드를 통한 자동화된 데이터베이스 유지보수 작업을 가능하게 합니다. 모니터링 : 데이터베이스 상태 모니터링 및 메트릭 수집을 간소화합니다. 일관성 : 데이터베이스 작업을 위한 표준화된 인터페이스를 제공합니다. 단점 # 성능 오버헤드 : 뷰는 접근 시 구체화(materialization)와 계산으로 인해 추가적인 쿼리 오버헤드를 유발할 수 있습니다. 디버깅 복잡성 : Ruby/Rails 레이어와 PostgreSQL 모두를 추적해야 하므로 디버깅이 더 어려워질 수 있습니다. 마이그레이션 어려움 : 스키마 마이그레이션 시 뷰를 신중하게 관리해야 합니다. 기반 테이블이 변경되면 뷰도 그에 따라 업데이트해야 합니다. Rails 마이그레이션은 일반 테이블만큼 뷰를 원활하게 처리하지 않습니다. 유지보수 오버헤드 : 뷰는 데이터베이스 스키마에서 유지보수해야 할 프로그래밍 언어 레이어를 하나 더 추가합니다. 테스트 복잡성 : 뷰에 의존하는 코드를 테스트하려면 더 많은 테스트 설정이 필요한 경우가 많습니다. 가이드라인 # 뷰를 사용할 때는 원시 SQL 쿼리 대신 적절한 스코프와 관계가 있는 ActiveRecord 모델을 항상 사용하십시오. 뷰는 설계상 읽기 전용입니다. 새 뷰를 추가할 때는 적절한 마이그레이션, 모델, 테스트, 문서가 준비되어 있는지 확인하십시오. 테스트 # 뷰를 테스트할 때는 swapout_view_for_table 헬퍼를 사용하여 뷰를 임시로 테이블로 교체하십시오. 이 방법으로 팩토리를 사용하여 뷰가 반환하는 것과 유사한 레코드