[MYSQL] DATETIME 타입에 DEFAULT 값으로 현재 시간 입력

개요

평소 DB 테이블을 생성할 때 날짜에 대한 부분은 Type 값을 DATETIME으로 주고

Service단 (또는 DB를 컨트롤하는 로직, 모듈) 에서 현재 날짜에 대한 부분을 변수에 담아 해당 변수를

INSERT 또는 UPDATE 해주었다.

하지만, 현재 날짜로 들어가는 regDate 같은 컬럼은 굳이 로직에서 따로 변수로 담아 할당해주지 않아도

DB에서 Auto increment 처럼 Row가 입력되면 자동으로 해당 컬럼에 현재 시간을 입력해줄 수 있다는 방법을 알게 되었다.

---

방법

나는 MySQL을 주로 사용하기 때문에 MySQL에 대한 방법만 포스팅을 하겠다.

 

 

- MySQL v5.6 이상 -

방법1

CREATE
	TABLE
    	TEST_TABLE(
        	regDate DATETIME DEFAULT CURRENT_TIMESTAMP
        );

 

방법2 

(이건 쿼리문에서 하는 방법인데 변수에 따로 할당 안하더라도 INSERT, UPDATE 시점에 편하게 사용가능하다.)

INSERT INTO test.testTable
	( regDate )
VALUES
	( now() );

 

---

※ 추가 ※

날짜관련 타입 중 DATETIME 말고도 TIMESTAMP가 있는데 둘 중 어떤 것을 써도

DEFAULT CURRENT_TIMESTAMP는 사용이 가능하다. 

하지만 두 타입의 차이점은 분명히 있다.

 

차이점1

MySQL의 TimeZone이 예를들어 Asia/Seoul 로 되어있고, datetime 컬럼과 timestamp 컬럼이

동일한 현재 시간 값으로 입력되어있다고 가정했을 때

+---------------------+---------------------+
| datetime            |   timestamp         |
+---------------------+---------------------+
| 2021-08-21 20:11:09 | 2021-08-21 20:11:09 |
+---------------------+---------------------+

 

TimeZone을 변경하면 

+---------------------+---------------------+
| datetime            |   timestamp         |
+---------------------+---------------------+
| 2021-08-21 20:11:09 | 2021-08-21 10:41:09 |
+---------------------+---------------------+

위와 같이 timestamp의 값이 바뀌는 현상이 발생된다. 

 

이유는 TimeStamp는 Time_Zone을 의존한다! ( TimeStamp -> Time_Zone )

 

개인적으로 생각했을 때 DATETIME을 사용하면 TimeZone이 바뀌어도 의존성이 없으니 데이터가 변동될 걱정이 없지 않은가? 라는 생각을 가질 수도 있지만

이렇게 따로 나눠놓은데에는 다 이유가 있다. ( 다 생각이 있다 이말이야 )

글로벌 서비스를 운영할 때 필요하다!

예를들어 서울에서 오후 3시쯤 작성한 게시물이 다른나라로 Replication 하는 경우에 해당 나라에서는 여전히 오후3시로 작성된 게시물로 보이게 된다. 

그래서 글로벌 서비스를 운영해야하는 경우에는 TimeZone이 반영되는 TimeStamp로 타입을 주는게 바람직하다고 볼 수 있다.

 

차이점2

 

- DateTime

• 1000-01-01 00:00:00부터 9999-12-31 23:59:59까지 지원

 

- TimeStamp

• 1970-01-01 00:00:01부터 2038-01-19 03:14:07까지 지원
• Index가 더 빠르게 생성된다.

 

 

---

참고 포스팅

• https://nesoy.github.io/articles/2020-02/mysql-datetime-timestamp

• https://jsonobject.tistory.com/122