MySQL 스타일 가이드

* Simon Holywell의 스타일 가이드 기반, GitLab과 Mozilla를 참조함

[요약]

- 예약어는 대문자, 변수들은 소문자(문자, 숫자, _만 사용함)

- Table은 집합명사, Columns는 단수명사를 사용하고 서로 중복되면 안된다. SELECT 문 내에서 별칭을 정한다.

- AS 키워드를 꼭 사용한다.
  각 단어의 첫 글자 또는  20글자 미만의 테이블 명, 그 외 경우 테이블명의 별칭(최소 4자 이상)을 사용한다. 

- boolean에는 has_, is_, does_ 접두사를, 모호한 접미사 앞에는 식별 대상을 붙여주어야 한다.
  ex) account_id, account_name : 식별 대상 account,  접미사 _id, _name

- 줄 바꿈은 변수는 Mozilla, 그 외는 Simon 가이드를 기반으로 한다.(GitLab 방식, 제일 가독성 좋아 보인다.)

SELECT
    budget_forecast.account_id,
    date_details.fiscal_year,
    date_details.fiscal_quarter,
    date_details.fiscal_quarter_name,
    cost_category.cost_category_level_1,
    cost_category.cost_category_level_2
FROM budget_forecast_cogs_opex AS budget_forecast
LEFT JOIN date_details
    ON date_details.first_day_of_month = budget_forecast.accounting_period
LEFT JOIN cost_category
    ON budget_forecast.unique_account_name = cost_category.unique_account_name​

- 명시적 JOIN을 사용한다.

---

[주석]

필요한 경우 SQL 코드에 주석 달기. 가능한 경우 또는 여러 줄로 된 주석은 /* */ 를 사용하고
가능하지 않은 경우 또는 짧은 주석 앞에 --를 붙이고, 새로운 줄로 마무리하라.

[Naming]

• 이름은 문자로 시작해야하며, 밑줄(_)로 끝나지 않는다. 연속된 밑줄의 사용을 피하라.
• 이름에 자연스럽게 포함되는 공백에 밑줄을 사용하라. (first name은 first_name이 된다.)
• 약어를 피하라. 약어를 사용해야 한다면, 일반적으로 이해되는지 확인하라.

<Tables>

• 집합명사를 사용하라. 어려운 경우 복수 형식을 사용하라. ex, (선호도 순서대로) staff, employees 이다.
• 테이블명을 해당 테이블을 구성하는 테이블 컬럼명과 동일하게 지정하지 말라.
• 가능한 경우, 두 개의 테이블 이름을 연결하여 관계 테이블의 이름을 만들지 말라. (cars_mechanics 보다 services를 선호한다.)

<Columns>

• 항상 단수명사를 사용하라.
• 가능한 경우, 단순히 id를 테이블의 기본 식별자로 사용하지 말라.
• 해당 테이블명과 동일한 이름의 컬럼을 추가하지 말라.
• 고유명사와 같은 경우가 아니라면, 항상 소문자를 사용하라.

권장되는 데이터 유형

데이터 유형
Character	VARCHAR / CHAR / CLOB
Numeric	BIGINT / DECIMAL / DECFLOAT / INTEGER / NUMERIC / SMALLINT FLOAT /  DOUBLE PRECISION / REAL (꼭 필요한 경우가 아니면 실수형 사용은 자제하기)
Datetime	TIMESTAMP / DATE / TIME
Binary	BINARY / BLOB / VARBINARY
Additional	BOOLEAN / INTERVAL / XML

<Aliasing or correlations>

• 일반적으로 correlation 이름은 개체 이름에 포함된 각 단어의 첫 글자가 되어야 한다.
• (GitLab) 테이블 이름이 20자 미만일 경우 별칭 대신 전체 테이블 이름을 참조,
  그 외의 경우 테이블 이름/별칭으로 한정한다.
  FROM budget_forecast_cogs_opex AS budget_forecast
• 이미 같은 이름의 correlation이 있는 경우, 번호를 붙인다.
• 항상 AS 키워드를 붙인다.
• 계산된 값(SUM() or AVG())이 스키마에 정의된 컬럼일 경우 이름을 부여하라.
  
  

  SELECT first_name AS fn
    FROM staff AS s1
    JOIN students AS s2
      ON s2.mentor_id = s1.staff_num;
  

  SELECT SUM(s.monitor_tally) AS monitor_total
    FROM staff AS s;​

<Stored procedures>

• 이름에 동사가 포함되어야만 한다.

<Uniform suffixes>

boolean column은 앞에 has_, is_, does를 붙여주어야 한다.

접미사	사용처
_id	기본키와 같은 고유 식별자
_status	flag 값 또는 기타 다른 유형의 상태값
_total	어떤 값들의 합계(sum) 또는 총합
_num	필드에 어떤 종류의 숫자들이 포함되어 있음을 나타냅니다
_name	이름을 나타냅니다
_seq	연속적인 값의 시퀀스를 나타냅니다.
_date	날짜가 포함된 컬럼을 나타냅니다.
_tally	카운트.
_size	크기
_addr	물리적인 주소이거나 ip_addr와 같은 무형의 주소일 수 있습니다.

---

[Query syntax]

<예약어>

• 항상 대문자를 사용하십시오.
• 축약된 키워드의 사용을 피하고, 가능한 경우 전체 길이의 키워드를 사용하는 것이 좋습니다.
  (ABS 보다 ABSOLUTE를 선호)
• 동일한 기능을 수행하는 ANSI SQL 키워드가 있는 경우 특정 데이터베이스 서버 특화된 키워드를 사용하지 마십시오.

<공백>

모든 경우에 해당되지는 않지만, 아래의 경우는 항상 공백을 사용합니다.

• 등호(=) 전, 후
• 쉼표(,) 뒤
• apostrophes(') 전, 후 (괄호 안 또는 쉼표나 세미콜론이 뒤에 오는 경우는 제외)

SELECT a.title, a.release_date, a.recording_date
  FROM albums AS a
 WHERE a.title = 'Charcoal Lane'
    OR a.title = 'The New Danger';

 

<줄 바꿈>

• AND 또는 OR 전
• 세미콜론 뒤 (쿼리를 구분하여 가독성이 좋습니다.)
• 각 키워드 정의 후
• 쉼표 뒤 (여러 개의 컬럼을 논리적 그룹으로 구분할 때)
  

  INSERT INTO albums (title, release_date, recording_date)
  VALUES ('Charcoal Lane', '1990-01-01 01:01:01.00000', '1990-01-01 01:01:01.00000'),
         ('The New Danger', '2008-01-01 01:01:01.00000', '1990-01-01 01:01:01.00000');​

• 큰 코드 덩어리(large chunks of code)의 가독성을 향상시키기 위해 코드를 관련된 부분으로 분리할 때
  

  SELECT a.title,
         a.release_date, a.recording_date, a.production_date -- grouped dates together
    FROM albums AS a
   WHERE a.title = 'Charcoal Lane'
      OR a.title = 'The New Danger';​

• Mozilla의 경우 다른 정렬 방식을 더 선호한다.
  

  SELECT
    client_id,
    submission_date
  FROM
    main_summary
  WHERE
    sample_id = '42'
    AND submission_date > '20180101'
  LIMIT
    10

<Indentation>

JOIN	들여쓰기, 필요한 경우 새로운 줄을 이용해 그룹화해야 한다.
Subqueries	들여쓰기, 다른 쿼리와 동일한 스타일

<Preferred formalisms>

• 여러 개의 AND 구문을 결합하기 보다는 BETWEEN을, OR 구문을 결합하기 보다는 IN()을 사용하라.
• 데이터베이스단에서 값을 해석해야하는 경우, CASE 구문을 사용하라.
  CASE 구문을 중첩하여 보다 복잡한 논리적 구조를 형성할 수 있다.
• 가능한 한 UNION 구문과 임시 테이블의 사용을 피하라.
  스키마를 최적화함으로써 UNION, 임시 테이블의 기능을 대체할 수 있다면 그렇게 해야 할 것이다.
  

  SELECT CASE postcode
         WHEN 'BN1' THEN 'Brighton'
         WHEN 'EH1' THEN 'Edinburgh'
         END AS city
    FROM office_locations
   WHERE country = 'United Kingdom'
     AND opening_time BETWEEN 8 AND 9
     AND postcode IN ('EH1', 'BN1', 'NN1', 'KW1');​

• 단일 CASE문이나 Boolean문의 경우,  IF를 더 선호함
• DATEDIFF
• !=
• LOWER(column) LIKE '%match%'
• WHERE
• [ ]로 JSON에 엑세스
• 공통 테이블 표현식(CTEs)
• EXTRACT

---

[Create syntax]

컬럼 정의 부분을 정렬하고 적절하게 그룹화해야 합니다. 
CREATE 구문 내에서 컬럼을 정의할 때에는 4개의 공백을 이용하여 들여 쓰기 합니다.

<Choosing data types>

• 가능한 경우, 벤더(산업) 특화된 데이터 타입을 사용하지 말라. 
• 엄격한 부동 소수점 연산이 필요한 경우에만 REAL 또는 FLOAT 타입을 사용하라.
  그렇지 않은 경우 항상 NUMERIC 또는 DECIMAL 타입을 선호하라.

<Specifying default values>

• 기본값은 항상 컬럼의 데이터 타입과 동일해야 한다.
  — 만약 컬럼이 DECIMAL로 선언되어 있다면, INTEGER 타입의 기본값을 설정하지 마라.
• 기본값은 데이터 타입 선언 뒤에 작성해야 하며, NOT NULL 문 앞에 작성되어야 합니다.

<Constraints and keys>

- Choosing keys and Defining constraints

1. 키는 고유해야 한다.
2. 스키마 전체에 걸쳐서 데이터 유형 측면에서 일관성이 있으며, 미래에도 변경될 가능성이 작아야 합니다.
3. 표준 형식(ISO에서 발표한 형식)에 대해 값을 검증할 수 있어야 합니다.
4. 키는 가능한 한 단순하게 유지하면서, 필요한 경우 복합키를 사용합니다.

• 테이블에는 하나 이상의 키가 있어야 완전하고 유용합니다.
• 데이터베이스 벤더에서 일반적으로 충분히 이해할 수 있는 이름을 자동적으로 제공하는 UNIQUE, PRIMARY KEY, FOREIGN KEY를 제외한 제약조건에는 사용자 지정 이름이 부여되어야 합니다.

- layout

• CREATE TABLE 구문 바로 뒤에는 기본키를 지정하십시오.
• 들여쓰기, 제약조건은 대응하는 컬럼 바로 아래에 정의되어야 합니다.
• 만약 다중 컬럼에 대한 제약조건인 경우, 가능한 한 두 컬럼의 정의 모두에 가깝게 배치하고 어려운 경우 마지막 수단으로 CREATE TABLE 정의 끝에 작성하는 것을 고려하십시오.
• 테이블 전체에 적용되는 테이블 수준의 제약조건의 경우, 맨 끝에 정의되어야 합니다.
• 알파벳 순서로 작성하십시오. (ON DELETE가 ON UPDATE 앞에 와야 합니다.)
• 가능한 경우 쿼리의 각 요소를 동일한 문자 위치로 정렬하십시오. 예를 들어, 모든 NOT NULL 구문을 동일한 문자 위치에서 시작하는 것입니다. 이는 어렵지도 않고 빠르지만, 코드를 훨씬 읽고 스캔하기 쉽게 만들어줍니다.

- Validation

• LIKE와 SIMILAR TO 제약조건을 사용하여 형식이 정해진 문자열의 무결성을 보장합니다.
• 수치값의 최대 범위가 정해져 있는 경우, 범위를 CHECK()로 작성해야 합니다.
  대부분의 경우 최소한 값이 0 이상인지 확인해야 합니다.
• CHECK() 제약조건은 디버깅을 쉽게 하기 위해 별도의 구문에 작성해야 합니다.

[참고 자료]
https://www.sqlstyle.guide/ko/#stored-procedures

SQL style guide by Simon Holywell

https://docs.telemetry.mozilla.org/concepts/sql_style#consistency

SQL Style Guide - Mozilla Data Documentation

https://handbook.gitlab.com/handbook/enterprise-data/platform/sql-style-guide/

SQL Style Guide