𝙎𝙌𝙇

날짜 'VARCHAR형' vs 'DATE형' 장단점 정리

콜라맛갈비 2023. 1. 4. 12:25
728x90

.▶ 날짜 'VARCHAR형' vs 'DATE형' 장단점 정리

  장점 단점 단점 해결방안
VARCHAR 1. 개발 운영 편의성

2. LIKE 검색의 편의성, 향후 데이터 가공의 편의성
1. 옵티마이저가 일자인지 인식하지 못함 -> 두 일자 BETWEEN 써서 데이터 조회 불가능

2. 날짜가 아닌 데이터가 들어갈 수 있음 (데이터 클렌징도 어려움)

3. 개발 생산성 저하 (일자 연산이 있을 경우 TO_DATE 등의 함수를 사용해야 함)

4. Date/Time형은 내부적으로 하나의 숫자로 처리지만, String형은 내부적으로 하나 하나의 문자로 처리되기 때문에 더 느림
1. 데이터 무결성 문제 -> 입력이나 수정시점에 필드에 대해 제약조건을 걸면 체크가 가능

2. date 함수 사용에 아무 문제없음
DATE 1. 공간적인 측면에서 효율적 (DATE : 7byte)

2. 데이터 정합성(날짜 범위를 벗어나더라도 에러가 발생하지 않음)측면에서 효율적

3. 인덱스 구현/사용하는 메커니즘의 속도가 훨씬 빠름

4. 문자함수, 날짜함수 모두 사용 가능
1. //초가 들어감으로써(datetime) 데이터가 조회되지 않을 수 있음
2. //초가 들어감으로써 개발효율성과 성능이 떨어짐

3. 년도나 월 데이터를 조회할 때 LIKE 사용 불가, BETWEEN 사용해야 함

4. SYSDATE 등을 INSERT할 때 TRUNCT 등의 함수를 사용하여 시//초를 잘라내야 함

5. 개발 비용이 2배 더 들어감

6. 날짜 + 코드 등에 겹합 인덱스 사용시, 예를 들어 2004123일에 10번 코드 라는 조건이 있다면 where Date/Time betwwen 시작 and and 코드='10' 이렇게 되므로 코드는 인덱스 활용이 불가능

7. 날짜끼리 연결해서 조인 발생시, 날짜만으로 조인이 이루어져야 되나 시간이 붙어 있으므로 날짜만 불러오기 위해 함수를 써야 되므로 인덱스를 활용한 조인이 어려움
1. 기간 검색 등에서 날짜 함수 이용할 수 있고 형변환 없이 인덱스 검색 가능

2. 형변환만 해주면 날짜함수 사용에 아무 문제없음

3. 시분초 부분을 000000으로 고정시켜버리면 단점 커버 가능

 

 

▶ VARCHAR, DATE 상황별 유리한 경우

-      VARCAHR

         -  검색조건이 필요한 경우 (니콜비교, 라이크비교 등)

         -  컬럼이 날짜로만 쓰이는 것이 아니라 예외적인 사항으로도 쓰이는 경우

-      DATE 

         -  날짜 칼럼, 시분초까지 들어가는 칼럼 사용 시

         -  입력일시 수정일시 같은 로그성 컬럼, 시분초까지 필요한 단순이력성 데이터

 

 

기타 의견

     -     대안책) 날짜와 시분초로 나누어서 결합 인덱스 구성

     -     일/시분초 데이터는 고정길이와 null 을 허용하지 않는 경우가 많아서 varchar2 보다는 char  선호

     -      글로벌 서비스라고 한다면 yyyymmdd 형식이 아닌 국가도 있음

 

 

 

728x90