필자는 작성한 데이터, 마지막으로 수정 한 데이터 등등에 사용하는 데이터 유형의 열을 가지고 있습니다.SQL Server 2008에서 null이 아니게하려면 어떤 기본 날짜를 사용해야합니까?
이 열이 null을 허용하지 않기를 바란다면 무엇을 사용해야하는지에 대한 모범 사례가 있습니다. 사용되지 않고 초기화 된 상태입니까?
datetime.minvalue 값은 무엇이든지 사용해야합니까?
사용하지 않는 날짜를 저장하려는 경우 NULL을 사용하는 것이 가장 좋습니다. 그것을 읽을 때 NULL을 확인하고 원하는 경우 DateTime.MinValue를 사용할 수 있습니다.
NULL을 사용해야합니다. 알 수 없거나 초기화되지 않은 값.
의견에서 언급했듯이 DateCreated을 null로 지정할 수 없습니다. 어떤 사람들은 우수하고 고도로 정규화 된 데이터베이스 설계가 전혀 null 값을 허용하지 않아야한다고 주장합니다 (예 : article 참조). 나는 동의하는 경향이 있습니다.
필자가 선호하는 것은 이러한 상황에서 열에 대해 getDate() 또는 getUTCDate()의 기본값을 설정하는 것입니다.
예를 들어 CreatedDate는 NULL이 아니어야합니다. 그렇지 않으면 이론적으로 레코드가 처음부터 존재하지 않아야합니다.
레코드가 있으면 레코드가 작성되었으므로 레코드도 수정되어 있으므로 수정 된 날짜의 기본값은 getDate() 일 수도 있습니다.
또한 데이터웨어 하우스의 레코드/행 변경 내용을 추적하는 데 일반적으로 사용되는 방법이기도합니다.
대부분의 경우 작성 <> 수정. 생성은 새로운 데이터 행을 추가하는 것입니다. 수정은 일반적으로 원래 생성 된 행을 변경합니다. –
또한, 응용 프로그램이 주어진 로케일에 묶여 있고 다른 곳에서 사용되지 않는 한,'GetUtcDate()'는'GetDate()'보다 항상 사용하는 것이 좋습니다. 하나 이상의 시간대를 다루기 시작하자마자, 다른 사람들의 현지 시간에 날짜를 저장하는 것은 아주 나쁜 생각이됩니다. –
@ 대니얼 프리 든 (Daniel Pryden) : 언급 할 가치가있는 중요한 점! –
이 열이 null을 허용하지 않기를 바란다. 사용되지 않은 초기화 된 상태에 대해 사용해야하는 측면에서 모범 사례가 있습니까?
null을 사용하고 싶지 않으므로 1753 년 1 월 1 일 0:00:00을 사용할 수 있습니다. 이 값은 SQL Server의 datetime에 대해 가능한 최소값이며 데이터 집합의 실제 값이 될 가능성은 낮습니다.
하지만 가능한 경우 실제로는 null을 사용해야합니다.
DateTime.MinValue가 datetime 데이터 형식 안에 들어 가지 않습니다. datetime2 데이터 유형을 사용할 수 있지만 다른 권장 사항처럼 NULL을 사용해야합니다.
자주 LastModified 또는 LastLogin과 같은 열을 만들고 기본값은 null입니다.
null을 보면 사용자가 데이터를 수정하거나 시스템에 로그인 한 적이 없다는 것을 신속하게 알 수 있습니다. 이 경우 NULL 값은 의미가 있습니다.
Null이 반드시 색인 생성이나 쿼리 (예 : 사이)에 적합하지는 않습니다. 필자는 비슷한 날짜를 요구하는 장소에서 01/01/0001 또는 12/31/9999를 사용하는 경향이 있습니다. (DATETIME2)
어떤 점에서 NULL이 작동하지 않습니까? 인덱스에서 정상적으로 작동합니다 (일반적으로 NULL 행이 먼저오고 실제 날짜가있는 행). BETWEEN (NULL 행은 조건이 맞지 않습니다.)과 완벽하게 작동합니다. –
예, DATETIME2와 함께 작동 할 수 있습니다.하지만 DATETIME의 경우 "01/01/0001"의 날짜는별로 재미 있지 않습니다 .-) ( –
당신의 열이 정말 Created 및 LastModified 인 경우에, 왜 그냥 GetDate() (또는 더 나은, GetUtcDate())를 사용하여 초기화? 이것이 파일 시스템이 새로 생성 된 파일의 datetime 스탬프를 초기화하는 방법입니다.
그러나 다른 사람들이 지적한 것처럼 null을 두려워 할 이유가 없습니다. "적용 할 수있는 가치가 없다"는 것을 실제로 의미한다면, null은 완벽하게 표현하는 좋은 방법입니다.
사용되지 않는 초기화되지 않은 상태는 정확히 NULL이 나타내는 것으로 설계되었습니다. 적절한 곳에서 NULL을 허용해야합니다 (예 : 무언가가 종료되지 않은 경우 TERMINATIONDATE 열에서). NULL이없는 경우 적절한 값을 사용하십시오 (예 : 행 추가시 DATECREATED와 같은).
NULL 날짜에 넌센스 값을 사용하는 것은 사용자에게 혼동을줍니다. "종료 날짜는 어떻게 2099 년이 될 수 있습니까? 우리는 아직 2099 년이 아닙니다!"또는 "종료일은 1732 년이 될 수 있습니까? 우리는 그때 존재하지 않았습니다!"
초기화되지 않은 것은 정확히 초기화되지 않은 것을 의미합니다. 그것은 "초기화되었지만 가짜 값을 가진"것을 의미하지는 않습니다.
2099 년에 앱이 계속 사용되고 있고 갑자기 모든 직원이 해지되었습니다! Y2.099K 버그 픽서를 위해 많은 일을하고 있습니다. – user9876
전적으로 NULL/GETDATE() 답변에 동의합니다.
일반적으로 모범 사례로, 정기적으로 랩 할 준비가되어 있지 않으면 특수 datetime 값을 저장하지 않아도됩니다. 당신이 등 DATEDIFF의 달 차이 수천 나오기 시작하면 임계 값을 추가하는 로직을 수정하는 데 끝낼 때문에
내가 날짜를 갈 규칙은 제약 조건 (특수 날짜 값과 NOT NULL 결코/테이블 정의) 에 특별한 예약 날짜 값이 필요하면이 필요하지 않으면 NULL을 사용하려고합니다. 예약 된 날짜가 여러 개 필요한 경우 datetime 열 대신 NULL이라는 개별 플래그 열을 사용하거나 datetime 열 대신 (특히웨어 하우징의 경우) 날짜 차원에 조인하십시오.
DateCreated 및 DateModified의 경우, 열 기본값을 사용하여 GETDATE()으로 초기화합니다. DateModified은 일반적으로 UPDATE 트리거에서 새로 고쳐집니다.
나는 그 날짜에 레코드를 입력 한 날짜를 제외하고는 아무것도 넣지 않을 것입니다. 그리고 나서 date_created 필드처럼 그렇게하는 것이 합당 할 때만입니다. 예를 들어, 다른 데이터에 사용될 가능성이없는 데이터를 사용하는 경우, 처음에는 데이터가 잘못되어 언젠가는 다시 돌아올 것입니다. 당신이 그런 바보 같은 짓을했다는 것을 모르는 사람은 언젠가 불완전한 기록을 찾고 언젠가 날짜가 있기 때문에 어떤 것도 발견하지 못할 것입니다. 또는 cetain 시작 날짜와 종료 날짜 사이의 레코드와 프로세스가 시작되었지만 종료되지 않은 레코드를 원한다고 가정하십시오. null이 아닌 가짜 날짜로 쿼리하는 것이 더 어렵습니다. 설정 한 날짜보다 더 정교한 레코드가 필요하다고 가정하면이 레코드를 제외해야한다는 것을 기억해야합니다. 그렇지 않으면 3000/1/01과 같은 날짜를 사용하는 경우 나중 레코드를 원할 경우 레코드 집합에 표시됩니다. . 따라서 이것은 null을 처리하기 위해 기억하는 것만큼이나 당신이 멀리있는 데이터베이스를 쿼리하는 것과는 거리가 멀고 그렇게 할 확률이 훨씬 적습니다. 따라서 날짜 중심 쿼리에 잘못된 결과가 자주 발생합니다.
Null은 데이터 입력시 값이 무엇인지 알 수없는 이러한 상황을 정확하게 나타냅니다. null을 사용하지 않으려면 데이터를 가짜로 작성하지 마십시오. 그것은 매우 가난한 실천입니다.
모범 사례가 실제로 무엇인지 알고 싶으면 NULL ... 토론 끝내기. 다른 선택은 우리가 덜 우월한 관행이라 부르는 것입니다. 평소와 같이 선택할 수있는 방법이 많지 않습니다. 여기에 언급 된 것들이 많이 있습니다!
왜 CreatedDate에 NULL을 사용합니까?레코드가 존재한다면 레코드가 생성되어 CreatedDate가 있어야한다고 생각했을 것입니다. –
Sansom, 그것의 문맥 사정; 무엇 LastModified 열에 넣어 최고의 가치? –
레코드가 수정되지 않은 경우 NULL은 LastModified 열에 넣는 데 가장 좋은 값입니다. –