a. 필요한 데이터가 어떤 것인지 모른다면 DB 설계는 할 수 없다.
- 응용 프로그램에 대한 이해는 필수이며, 그 외에도 자료형은 어떤 것인지, 자릿수와 같은 표시상 사용자 편리성 데이터도 저장해야 하는지 등도 고려해야 한다.
b. 중복으로 저장된 데이터 항목을 제거하자
- 데이터를 중복으로 저장하면 일관되지 않은 데이터, 비정상적인 삽입/갱신/삭제 처리, 디스크 공간 낭비 등의 문제가 발생한다.
- 정규화는 중복을 줄이고 무결성을 향상하는 데 초점을 둔 작업이다. 중복을 해결함으로써, 데이터간의 모순을 방지할 수 있어, 질의해야할 대상이 명확해진다.
- DB 역시 데이터의 본질을 표현하는 적절한 네이밍이 중요하다. '명명 규칙을 통일'하지 않아 각 속성의 의미가 모호할 경우, 잘못된 설계를 할 수 있다.
c. 컬럼당 하나의 특성만 저장하자
- '서울 송파구 올림픽로 295 우아한형제들 작은집' 을 한 칼럼에 저장할 경우 시/구/거리/건물이름 등으로 조회하기 어렵다.
d. DB에 종속적인 설계를 지양하자
- 트리거를 사용해 계산 컬럼을 작성할 수 있다. 하지만 이 경우 요구사항이 변경될 경우 테이블 스키마도 변경해야 하며 관리 포인트가 증가하여 유지보수하기가 어렵다. 또한 데이터를 갱신할 때마다 시스템에 추가적인 부하를 일으킬 수 있으며, 저장공간이 증가한다.
- 프로시저에서 비즈니스 로직을 관리할 경우 역시 마찬가지다.
e. 모든 테이블에 기본키가 있는지 확인하자
- 테이블에 기본키가 없으면 반복적이고 일관성 없는 데이터가 쌓여 쿼리 수행 속도가 느리고, 부정확한 정보를 조회하게 될 수 있다.
SQL문 작성 권장 규칙
권장일 뿐, 아래의 규칙들을 반드시 지켜야만 하는 것은 아니다.
테이블, 필드 등 명명규칙의 경우, microsoft(Pascal), mysql(lowercase) 의 Convention이 상이하다. 다만, 일관성있게 작성하자.
대소문자를 구별하지 않는다.
한줄 또는 여러 줄로 작성할 수 있다
명령어를 대문자로 작성하고 나머지를 소문자로 작성한다
예약어는 사용할 수 없다.
들여쓰기 규칙은 아래와 같다.
- SELECT 절은 들여쓰기 하지 않는다.
- UNION 절은 그 다음 SELECT와 함께 작성한다.
- 칼럼은 한 줄마다 작성한다.
- FROM 절의 테이블 목록, WHERE 절의 검색 조건 목록은 한 줄씩 작성한다.
- 서브쿼리의 괄호는 각각 한 줄로 작성한다.
반응형
'우아한테크코스' 카테고리의 다른 글
준 강의 - 프론트엔드 기본 꿀팁 (0) | 2020.05.15 |
---|---|
api 설계 (0) | 2020.05.12 |
테스트하기 어려운 코드 (0) | 2020.03.31 |
람다와 스트림 (0) | 2020.03.20 |
클래스와 인스턴스 (0) | 2020.03.17 |