database SQL 포맷터 star

작동 원리

한 줄로 작성된 긴 SQL 쿼리는 구조를 한눈에 파악하기 어렵습니다 — WHERE 절은 어디서 끝나고 GROUP BY는 어디서 시작하는지, 어떤 JOIN이 어떤 테이블에 속하는지 알기 힘듭니다. 이 도구는 원본 SQL을 받아 주요 절 경계마다 별도의 줄로 나눕니다: SELECT, FROM, WHERE, JOIN 계열 전체(INNER JOIN, LEFT JOIN, RIGHT JOIN 등), GROUP BY, ORDER BY, HAVING, UNION. AND/OR로 연결된 조건과 ON 뒤에 오는 조인 조건은 그것이 속한 절 아래 한 단계 들여쓰기되며, 키워드는 선택적으로 대문자로 통일됩니다. select id,name from users where active=1 and role='admin' order by name 같은 쿼리는 SELECT, FROM, WHERE, ORDER BY가 각각 자신만의 줄에서 시작하고 AND 조건이 WHERE 아래에 들여쓰기되는 블록이 됩니다 — 정보는 동일하지만, 코드 리뷰에서 사람이 손으로 작성했을 법한 형태로 배치될 뿐입니다.

이는 손으로 하기 가장 어려운 바로 그 지점에서 가장 큰 힘을 발휘합니다: 여러 테이블을 조인한 쿼리, WHERE 절 안에 파묻힌 서브쿼리, 여러 분기를 가진 CASE 표현식 등입니다. 일관된 들여쓰기 덕분에 검토자는 한 글자씩 읽어 내려가는 대신 누락된 조인 조건이나 잘못 놓인 괄호를 한눈에 알아챌 수 있습니다.

알아두어야 할 점

이것은 포맷터이지 검증기가 아닙니다 — 인식하는 고정된 키워드 집합을 기준으로 공백과 줄바꿈만 재배치할 뿐, 쿼리를 구문 트리로 파싱하지도, 데이터베이스에 대해 실행하지도 않습니다. 진정으로 방언을 인식하는 검증기가 되려면 각 SQL 변형마다 완전한 파서가 필요한데, MySQL, PostgreSQL, SQL Server, SQLite는 식별자 인용 방식, 날짜 함수, 심지어 어떤 문장이 유효한지에 이르기까지 세부적으로 서로 다르기 때문입니다 — 이런 것을 검증하는 척하는 얕은 브라우저 측 검사는 잘못된 안도감만 줄 뿐입니다. 포맷된 결과가 이상해 보인다면 대개 입력에 이미 오타나 짝이 맞지 않는 괄호가 있었다는 뜻입니다. 이 도구는 그것을 표시하는 대신 그 주위를 감싸서 포맷할 뿐입니다.

순전히 텍스트 배치만 다루기 때문에 운영 환경의 쿼리에도 안전하게 사용할 수 있습니다: 식별자, 문자열 리터럴, 숫자 값, 연산자는 절대 다시 쓰이거나 추가되거나 제거되지 않습니다 — 오직 공백과 (선택적인) 키워드 대소문자만 바뀝니다. 아무것도 어디로도 전송되지 않고 실행되지도 않습니다. 쿼리는 브라우저를 절대 벗어나지 않습니다.