SQL Server MVP 53이라는 책에 Louis Davidson의 글이 있어서 옮겨 적습니다.

확실하지 않은 값도 가질 수 있도록 한다면 열에 NULL을 허용하도록 설정해도 무방하다.

하지만 대부분의 경우에는 설계하는 사람이 별생각 없이 그냥 NULL 허용으로 두거나 코드에서 이를 관리하도록 맡겨버린다.

이 경우 다음과 같은 두 가지 문제점이 있다.

• SQL Sever 엔진은 쿼리를 더 빨리 수행하기 위해 모든 정보들을 참조한다.

따라서 쿼리 최적화기로 하여금 값이 NULL인지를 판단하지 않도록 하기 위해서는 반드시 값을 입력하도록 해야 한다.

• NULL 값이 없어야 하는 경우에 NULL 허용으로 설정해 놓으면 주기적으로 NULL 값이 있는지를 검사하는 작업을 수행해줘야 한다.

NULL 허용하지 않음으로 설정하기만 하면 UI에서 입력되는 데이터와는 상관없이 항상 NULL이 아닌 제대로 된 값만 저장되도록 할 수 있다.

이러한 이유들로 인해, NULL이 발생해서는 안 되는 열에 대해서는 반드시 NULL 허용을 하지 않도록 해야 한다.

NULL에 대해서는 더 깊이 설명하지는 않고 이것으로 마치겠지만 NULL에 대한 재미있는 비교 동작에 대해서는 좀 더 자세히 살펴볼 것을 권장한다.

이번 절에서 말하고자 하는 것은 NULL이 유용한 도구일 수는 있지만 NULL 허용을 시용하게 되면 불필요한 NULL 값의 입력을 막는 책임은 본인에게 있다는 것이다.

또한, NULL의 비교를 제대로 처리하지 않으면 생각했던 방식이 아닌 다른 방식으로 쿼리가 처리될 수도 있다는 것도 명심해야 한다.

네, 위 설명은 프로그래밍 기법에 관한 좋은 고려사항 이군요

성능면을 보면 null 은 default 값 보다 빠를 수 있습니다.

1.

"만약 어떤 테이블을 구성해야 하는데, 100개의 필드가 필요하고 하나의 행은 어떤 type 컬럼의 값에 따라 쓰이는 필드가 다르고 타입에따라 쓰는 필드는 소수이다. " 라는 가정을 해보겠습니다.

idx type, c1, c2, c3, c4.... c100

1 , typeA, c1value, null, null, null, null

2 , typeB, c1value, c2value, null, null, c100value

3 , typeC, c1value, null, c3value, null, c100value

4 , typeA, c1value, null, null, null, null

5 , typeB, c1value, c2value2, null, null, c100value

이런 상황에서 전체 전체 scan 이 필요한 쿼리가 있다면, null 이 있다면 성능은 비약적으로 빨라질 수 있습니다.

null 은 null bitmap 을 이용한 처리를 하고 실제 값을 넣지 않기 때문입니다. 그러므로 스토리지 공간도 적게 사용 합니다.

2.

mssql 에서 null 은 인덱스를 사용합니다.

만약 논리적으로 의미를 부여한 null 이 필요하고, null 을 찾을 경우가 있고 해당 컬럼에 where predicate 로 검색하면 인덱스를 잘 사용해 검색 합니다. default 와 검색 속도는 같습니다.

위 내용과 아래 내용을 머지해서 보시면 null에 대한 이해도를 더 높일 수 있겠네요