[sql-server] 데이터베이스에 시간 (hh : mm)을 저장하는 가장 좋은 방법

DATETIME 시작 DATETIME 종료

대신 event_start 및 event_end 와 같은 레이블이 붙은 두 개의 DATETIME 값 을 사용 하시기 바랍니다 .

시간은 복잡한 사업

이제 세계 대부분이 대부분의 측정에 대해 옳든 그르 든 데 너리 기반 미터법을 채택했습니다. 이것은 전반적으로 좋습니다. 왜냐하면 적어도 우리 모두는 ag가 ml이고, 입방 cm라는 것에 동의 할 수 있기 때문입니다. 적어도 대략 그렇게. 미터법에는 많은 결함이 있지만 적어도 국제적으로는 지속적으로 결함이 있습니다.

그러나 시간이 지남에 따라 우리는 있습니다. 1 초에 1000 밀리 초, 60 초에서 1 분, 60 분에서 1 시간, 반나절마다 12 시간, 월별 약 30 일, 해당 월 및 연도에 따라 다르며, 각 국가는 다른 국가와 시간 오프셋이 있습니다. , 시간 형식은 국가마다 다릅니다.

소화해야 할 것은 많지만 길고 짧은 것은 그러한 복잡한 시나리오가 간단한 해결책을 갖는 것이 불가능합니다.

일부 모서리는 잘릴 수 있지만 더 현명한 부분이 있습니다.

여기에 대한 최고의 답변은 자정 이후에 몇 분의 정수를 저장하는 것이 완벽하게 합리적으로 보일 수 있음을 시사하지만 어려운 방법으로 그렇게하는 것을 피하는 법을 배웠습니다.

두 개의 DATETIME 값을 구현하는 이유는 정확도, 해상도 및 피드백의 증가 때문입니다.

이는 디자인이 원하지 않는 결과를 생성 할 때 매우 유용합니다.

필요한 것보다 더 많은 데이터를 저장하고 있습니까?

처음에는 내가 필요로하는 것보다 더 많은 정보가 저장되고있는 것처럼 보일 수 있지만이 히트를 가져야 할 좋은 이유가 있습니다.

이 추가 정보를 저장하면 거의 항상 장기적으로 시간과 노력을 절약 할 수 있습니다. 왜냐하면 누군가 무언가가 얼마나 오래 걸 렸는지 들었을 때 이벤트가 언제 어디서 일어 났는지 알고 싶어하기 때문입니다.

거대한 행성입니다

과거에 나는이 행성에 내 나라 외에 다른 나라가 있다는 것을 무시한 죄를지었습니다. 당시에는 좋은 생각처럼 보였지만 이로 인해 항상 문제, 두통 및 시간 낭비가 발생했습니다. 항상 모든 시간대를 고려하십시오.

씨#

DateTime은 C #의 문자열로 멋지게 렌더링됩니다. ToString (string Format) 메서드는 간결하고 읽기 쉽습니다.

예

new TimeSpan(EventStart.Ticks - EventEnd.Ticks).ToString("h'h 'm'm 's's'")

SQL 서버

또한 응용 프로그램 인터페이스와 별도로 데이터베이스를 읽는 경우 dateTimes는 한 눈에 읽을 수 있으며 계산을 수행하는 것은 간단합니다.

예

SELECT DATEDIFF(MINUTE, event_start, event_end)

ISO8601 날짜 표준

SQLite를 사용하는 경우이 기능이 없으므로 대신 텍스트 필드를 사용하고 ISO8601 형식으로 저장합니다.

‘2013-01-27T12 : 30 : 00 + 0000’

노트:

• 24 시간제를 사용합니다 *

• ISO8601의 시간 오프셋 (또는 +0000) 부분은 GPS 좌표의 경도 값에 직접 매핑됩니다 (일광 절약 또는 전국을 고려하지 않음).

예

TimeOffset=(±Longitude.24)/360 

… 여기서 ±는 동쪽 또는 서쪽 방향을 나타냅니다.

따라서 데이터와 함께 경도, 위도 및 고도를 저장할 가치가 있는지 고려할 가치가 있습니다. 이것은 응용 프로그램에 따라 다릅니다.

• ISO8601은 국제 형식입니다.

• 위키는 http://en.wikipedia.org/wiki/ISO_8601 에서 더 자세한 정보를 얻을 수 있습니다.

• 날짜와 시간은 국제 시간으로 저장되며 오프셋은 시간이 저장된 위치에 따라 기록됩니다.

내 경험상 프로젝트를 시작할 때가 있다고 생각하는지 여부에 관계없이 항상 전체 날짜와 시간을 저장할 필요가 있습니다. ISO8601은 매우 훌륭하고 미래를 보장하는 방법입니다.

무료 추가 조언

체인처럼 이벤트를 함께 그룹화하는 것도 가치가 있습니다. 예를 들어 레이스를 기록하는 경우 전체 이벤트를 racer, race_circuit, circuit_checkpoints 및 circuit_laps별로 그룹화 할 수 있습니다.

제 경험상 누가 기록을 저장했는지 확인하는 것도 현명합니다. 트리거를 통해 채워진 별도의 테이블 또는 원래 테이블 내의 추가 열로.

더 많이 넣을수록 더 많이 나옵니다.

나는 가능한 한 공간적으로 경제적이 되려는 욕구를 완전히 이해하지만 정보를 잃어 버리는 대가로 그렇게하는 경우는 거의 없습니다.

데이터베이스의 경험 법칙은 제목에서 알 수 있듯이 데이터베이스는 데이터가있는만큼만 알려줄 수 있으며, 공백을 메우고 과거 데이터를 살펴 보는 데에는 비용이 많이들 수 있습니다.

해결책은 처음에 올바르게하는 것입니다. 이것은 말처럼 쉬운 일이지만 이제는 효과적인 데이터베이스 디자인에 대한 더 깊은 통찰력을 가지고 있어야하며, 이후에 처음부터 올바르게 만들 가능성이 훨씬 더 높아야합니다.

초기 설계가 좋을수록 나중에 수리 비용이 적게 듭니다.

내가 시간을 거슬러 올라갈 수 있다면 내가 거기에 도착했을 때 나 자신에게 말할 것이기 때문입니다.

답변

SELECT CAST(0.5 AS DATETIME)
--1900-01-01 12:00:00.000