"SQL 안티패턴" 내용 요약
2018년 11월 01일
  • 논리적 데이터베이스 설계 안티패턴
    • 무단횡단
      • 관련된 값의 집합을 한 칼럼에 저장할때, 여러 데이터를 쉼표 등으로 구별해서 넣지말고 다대다 테이블을 생성하라.
      • 당연한 말이다. 제 1 정규화 조건이기도하다. 단, 추가적으로 다대다 테이블에 연결된 데이터들이 리스트 쿼리에 나가야만 하는 경우에는 캐싱 역할을 하는 필드가 필요한 경우도 있다. 리스트 내에 서브쿼리는 더 안좋은 안티패턴이기 때문에.
    • 순진한 트리
      • 트리 형태의 데이터를 저장할 때는 parent_id 대신 다른 방법을 쓰자.
      • 아직 복잡한 트리형태의 데이터를 다루지 않기 때문에 계층구조는 parent_id를 통해 설계하고 있다.
    • 아이디가 필요해
      • 모든 테이블에 id 컬럼을 넣는 것은 안티패턴이다. bugs 테이블이라면 bug_id 형태로 지어라.
      • 공감하지 않는다. id 필드가 혼란을 야기할지는 잘 모르겠다. 오히려 코드를 작성할 때 bugs.bug_id 식으로 작성하게 될텐데 의미의 중복이 발생하고 다른 테이블에서 조인시에 alias로 구별해도 충분하다고 생각한다.
    • 키가 없는 엔트리
      • FK를 사용하라. 그렇지 않을 시 검증 코드를 추가 작성하는 책임이 필요하다.
      • 데이터의 무결성 차원에서는 당연히 추가해야 하는게 맞지만, 오히려 개발 & 테스트 중 제약이 많아져 생산성이 저하되는 점도 무시할 수 없다. 검증 코드 등은 단위 테스트로 커버 가능하다. 케이스마다 다르겠지만 내가 거쳐온 프로젝트에서는 FK를 걸지 않았고 그로 인한 큰 문제를 겪어본 적은 없다. 큰 프로젝트에서는 얘기가 다르겠지만. 상황에 맞춰 적용하는게 좋을듯.
    • 엔티티-속성-값
    • 다형성 연관
      • 이중 목적의 FK가 필요한 경우는 설계를 다시 생각해봐라.
    • 다중 칼럼 속성
      • 다중 값 속성 저장 이슈. 속성이 한테이블에 들어가야 할 것처럼 보이는데 여러개의 값을 가지는 경우
      • ex) Bugs 테이블 안에 tag1, tag2, tag3 필드 나열 대신 종속 테이블을 생성 ( bug_id를 가지는 Tags 테이블 )
      • 당연한 케이스. 저 동적인 필드 수가 고정인게 보장되지 않는 이상 테이블을 추가하는게 맞다고 생각한다.
    • 메타데이터 트러블
      • 데이터가 커질 시에 값으로 들어갈 걸 테이블 이름에 넣고 하지 말고 ( Bugs_2009, Bugs_2010 ...) 파티션을 해라.
  • 물리적 데이터베이스 설계 안티패턴
    • 반올림 오류
      • FLOAT, DOUBLE 등 대신 NUMERIC, DECIMAL 타입을 사용해라. 이게 더 정확하니까.
    • 31가지 맛
      • 컬럼의 값이 고정된 집합 내에서 나와야 할때 CHECK 제약조건을 쓰는대신 인덱스 테이블을 만들어서 참조하게 하라.
      • 집합이 동적인 경우는 당연히 테이블을 따로 뽑아야겠지만, 집합이 명확하다면 ( 성별 등 ) 그럴 필요는 없을듯
    • 유령파일
      • 파일을 저장할때 path만 저장하지 말고 blob으로 저장해라. 삭제가 되지 않고 쌓이는 파일이 생기기 때문.
      • 그렇다고 blob을 쓰는 건 좀....
    • 인덱스 샷건
      • 인덱스를 적절히 사용해라. 그렇다고 불충분하게 많이 할 필요는 없다.
      • where 절에 걸리는 필드 등은 전부 건다고 생각해도 좋을듯 하다. 불충분하게 많이 거는게 안거는 것보단 낫다.
  • 쿼리 안티패턴
    • 모르는 것에 대한 두려움
      • null은 사용하지 말자.
      • 그래서 모든 필드는 not null로 사용하고 있다. outer join 등으로 빈 필드가 나올 경우는 제외하고는 모두.
    • 애매한 그룹
    • 임의(random)의 선택
    • 가난한 자의 검색 엔진
      • 텍스트 검색 시 LIKE '%text%' 대신 다른 방법을 알아봐라. 풀텍스트 인덱싱 등.
    • 스파게티 쿼리
      • 한 쿼리로 안되겠다 싶으면 어러 쿼리로 나눠라.
    • 암묵적 칼럼
      • select 시 컬럼명을 지정하고 와일드카드(*)를 피해라.
  • 애플리케이션 개발 안티패턴
    • 읽을 수 있는 패스워드
      • 패스워드는 평문이나 복호화 가능한 값으로 저장하면 안된다. 당연
    • SQL 인젝션
      • 이것도 보안의 기초 체크사항이므로 생략
    • 가상키 편집증
      • id 값의 빈틈을 채우려는 순간 문제가 터지기 시작하므로 하지 말자.
      • 이런 경우가 있을려나
    • 나쁜 것 안 보기
      • SQL 작성 시 에러 코드 추가의 필요성
    • 외교적 면책특권
      • SQL도 코드처럼 문서화 테스트, 소스 코드 관리와 같은 것이 필요하다.
    • 마법의 콩
      • MVC, 모델을 단순히 데이터 접근 객체로 취급하면, 비즈니스 로직이 모델 외부인 컨트롤러 클래스에 걸쳐 존재하게 되고 모델 동작의 응집도가 낮아짐 ( Anamic Domain Model )