날짜와 시간을 별도의 열에 유지해야 할 이유가 있습니까?

날짜와 시간을 별도의 열로 유지하려는 소프트웨어 공급 업체의 결정을 이해하려고합니다. 예를 들어, 행이 작성되거나 업데이트 된시기입니다. 시간과 날짜는 모두 DateTime 열입니다. 우리는 SQL Server 2005를 사용하고 있습니다.

데이터베이스는 ERP 시스템의 데이터를 보유하고 있으며 가장 큰 테이블에는 약 3 백만 행이 있다고 생각합니다. 대부분의 테이블은 대략 1 만-1 만 행 사이입니다.

개인적으로 기본적으로 단일 타임 스탬프에 대해 단일 DateTime을 선택합니다. 이것은 더 쉬운 시차 계산을 가능하게하고 날짜 및 시간 부분은 타임 스탬프로부터 쉽게 추출 될 수 있습니다. 또한 적은 공간을 소비합니다.

날짜와 시간을 구분하는 것은 나쁜 습관입니까, 아니면 제가 이해할 수없는이 디자인에 매우 훌륭한 것이 있습니까?

내 생각에 그것은 레거시 지원 일 것입니다 (즉, 소프트웨어 버전 1로 돌아 가면 별도의 필드에 날짜와 시간이 있었고 항상 그렇게 작동했기 때문에 지원해야했습니다).

즉, 날짜와 시간을 구분하는 것이 훌륭하지 않으므로 누락 된 것이 없습니다.

(또 다른 옵션은 ERP 시스템 개발자가 날짜 시간 필드에 날짜 와 시간을 저장할 수 있다는 것을 알지 못했지만 이전 버전과 동일하게 작동하도록 비즈니스 요구 사항이있을 가능성이 훨씬 큽니다.)

일반적으로 사용법에 따라 다릅니다. 많은 쿼리가 하위 요소를 결합하는 경우 대신 함께 저장 한 다음 드문 경우에 분리해야하는 오버 헤드를 고려하십시오. 물론 분할은 때로는 더 복잡하거나 불가능 합니다. person_full_name추출해야하는 속성을 고려하십시오 person_family_name. 즉, 임시 값을 다운 캐스팅하는 것은 쉽지 않으므로 일반적으로 날짜와 시간을 함께 저장하는 것이 좋습니다.

또한 제약 조건 (및 아마도 트리거)을 사용하여 동기화되지 않도록 함께 저장하고 따로 저장하는 것이 좋습니다.이 방법을 사용하면 쿼리 시점이 아닌 업데이트 시점에서 분할 / 조인이 발생합니다. 데이터.

운영 체제에서 이것을 많이 사용하는 것을 볼 수 없습니다. 분석 시스템에서는 '일수'로 구성된 별도의 날짜 차원을 원할 수 있으므로 날짜가보고 롤업과 연결되며, 어떤 이유로 든 시간별로 분석하려는 경우 '시간'열 .

핵심 날짜 시간 열을 기준으로 날짜 및 시간을 계산 열로 표시 할 수도 있습니다.

ConcernedOfTunbridgeWe의 의견에 추가하기 위해 DateDimension 및 TimeDimension 테이블이 있으면 쿼리 성능 이점이 있습니다. 팩트 테이블에 dateDimensionKey와 TimeDimensionKey가 모두 있다고 가정하십시오. 오전 8시에서 오후 5시 사이의 숫자를 찾으려면 간단히 할 수 있습니다.

SELECT COUNT(1) FROM FactTable f Inner Join TimeDimension t on f.TimeDimensionKey = t.TimeDimension WHERE t.Hour BETWEEN 8 AND 17.

TimeDimensionKey에 인덱스를 추가 한 경우 팩트 테이블의 결과에 대한 인덱스 검색만으로 데이터를 검색 할 수 있습니다.

TimeDimension 테이블이 없으면 다음과 같은 작업을 수행해야합니다.

SELECT COUNT(1) FROM FactTable f WHERE DatePart(mintue, f.Date) BETWEEN 8 AND 17

데이터베이스 엔진은 어떤 데이터를 리턴 할 수 있는지 파악하기 전에 모든 행의 결과를 계산해야하기 때문에 테이블 스캔이 필요할 수 있습니다.