분당김동수 2014-08

보기에 따라, 직관적인 부분이 있는 것 같습니다.

또한 어디에서 가공해서 쓰느냐의 문제 아닐까요 ?
(DB 가 일할래 ? WAS 가 일할래 ?)

어린왕자 2014-08

구버전에서 date 비교 연산보다 varchar 비교 연산이 빨랐다는
요즘에는 데이터무결성이나 연산측면에서도 다시 date를 쓰는데...

정현태 2014-08

큰 의미는 없다고 봅니다. 저는 항상 int 타입으로 timestamp 값을 이용합니다.

반갑습니다 2014-08

빙고

조영민 2014-08

그 컬럼을 어디서 어떻게 쓰느냐 따라서 date를 쓰기도 Varchar나 Char 쓰기도 합니다.

회원K 2014-08

관점의 차이일 뿐 입니다. 뭘 쓰던 큰 차이 없습니다.

단군신화찬… 2014-08

필드별 데이터 유형을 해주시는것이 맞습니다..

그러나 보통 개발을 하다 보니 데이터 유형까지 신경써서 하기에는 방대한 프로젝트가 힘들지요.

또한 필드가 변경이 되던가 밀리던가 하다보면 또 데이터 유형까지 변경하고 관리하기가 힘들지요.

또 유형별로 데이터 입력 갯수가 정해저 있다보니 에러가 나던가 아니면 자료가 짤리던가 하지요...

이런 저런 이유로 Varchar 를 그냥 보편적으로 사용하지 않을까 생각 해봅니다.

김상진 2014-08

장단점이 있습니다.

다만,장점이란게....대부분 SQL을 작성하는 개발자의 편의를 위한 장점이라고 봅니다.

굳이 DATE형을 안쓰고 VARCHAR형을 쓰는건 주로 날짜나 시간들을 검색할때 형변환하는게 귀찮은경우에 주로 개발자들이 선호하더군요
예를 들자면.....오늘 입력된 데이터를 찾을려고 한다면
오라클 기준으로 DATE타입 컬럼이라면 TO_CHAR(컬럼명,'YYYYMMDD') = '20140805' 이런식으로 써야되는데
이걸 그냥 날짜 컬럼, 시간 컬럼을 나눠서 사용해서 그냥 "날짜컬럼" = '20140805' 이런식으로 훨씬 간단하게 쓸수있는거죠


나머지 경우에는
기존 데이터가 분명 DATE 타입의 컬럼인데 잘못된 데이터가 있어서 DATE 타입으로 쓸수없는 경우도 있습니다.
또는 개발할때 사용하는 프레임워크나 툴에서 날짜타입으로 데이터를 처리못하는 좀 구린(?) 제품들이 있긴하는거 같더군요



문제점은 잘못된 데이터가 들어가더라도 데이터가 입력되어버리죠...
예를 들어서 20140832 와 같이 8월 32일이 입력되어버리는거죠
이런경우 , 프로그램이 잘못된경우 문제가 될수있죠


그리고, DATE 타입은 보기에는 길게 보이지만, 실제 VARCHAR로 년/월/일/시/분/초로 나누는것보다 저장공간을 더 적게 사용할겁니다.
(아마도요...)

어찌되었던, 반드시 날짜타입은 DATE 형을 쓰는걸 권장합니다.
<== 이게 기본이죠

잔혹한마법사 2014-08

년/월/일/시/분/초 의 경우..
vharchar형은 14

oracle은 소수점 미 포함시 7

ms-sql은 datetime형의 경우 8

강승훈 2014-08

데이터 양보다는 나중에 프로그램상에서 렌더할때 코스트가 더 중요하다고는 생각하는데요... 개인적으로 datetime같은경우 많은 tool과 package들이 벌써 있으니까 더 좋지 않은가 하는 생각이 들거든요... 굳이 만들어논 바퀴를 새롭게 또 만들어서 쓸필요가 있나 하는 생각입니다..

"Don't Reinvent The Wheel"
제가 아주 좋아하는 말중에 하나입니다만...

잔혹한마법사 2014-08

기법보다 기본이 우선이죠.
varchar형만 존재하는 것이 아닌 여러종류의 데이터형이 있다는 것은 용도에 맞게 사용하라는 얘기니까요.

반대로...
무조건 한글자를 저장해야할 곳에 char(1)을 쓰는 대신 int형으로 ascii나 unicode값을 넣으려고는 아무도 하지 않는 것 처럼 말이죠..