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. 날짜 + 코드 등에 겹합 인덱스 사용시, 예를 들어 2004년12월3일에 10번 코드 라는 조건이 있다면 where Date/Time betwwen 시작 and 끝 and 코드='10' 이렇게 되므로 코드는 인덱스 활용이 불가능 7. 날짜끼리 연결해서 조인 발생시, 날짜만으로 조인이 이루어져야 되나 시간이 붙어 있으므로 날짜만 불러오기 위해 함수를 써야 되므로 인덱스를 활용한 조인이 어려움 |
1. 기간 검색 등에서 날짜 함수 이용할 수 있고 형변환 없이 인덱스 검색 가능 2. 형변환만 해주면 날짜함수 사용에 아무 문제없음 3. 시분초 부분을 000000으로 고정시켜버리면 단점 커버 가능 |
▶ VARCHAR, DATE 상황별 유리한 경우
- VARCAHR
- 검색조건이 필요한 경우 (니콜비교, 라이크비교 등)
- 컬럼이 날짜로만 쓰이는 것이 아니라 예외적인 사항으로도 쓰이는 경우
- DATE
- 날짜 칼럼, 시분초까지 들어가는 칼럼 사용 시
- 입력일시 수정일시 같은 로그성 컬럼, 시분초까지 필요한 단순이력성 데이터
▶ 기타 의견
- 대안책) 날짜와 시분초로 나누어서 결합 인덱스 구성
- 일/시분초 데이터는 고정길이와 null 을 허용하지 않는 경우가 많아서 varchar2 보다는 char 를 선호
- 글로벌 서비스라고 한다면 yyyymmdd 형식이 아닌 국가도 있음
728x90
'𝙎𝙌𝙇' 카테고리의 다른 글
inner join과 left outer join 비교 (0) | 2023.01.10 |
---|---|
rank와 dense_rank 차이 (0) | 2023.01.10 |
[MySQL] 프로그래머스 SQL 고득점 Kit (0) | 2023.01.06 |
테이블의 데이트형 확인 (0) | 2023.01.05 |
현재 스키마의 모든 테이블 목록 검색 (0) | 2023.01.05 |