Oracle에서 널 입력 가능 숫자를 사용하지 않는 이유는 무엇입니까?

우리 회사는 공동 프로젝트를 위해 다른 소프트웨어 회사와 인터페이스하고 있으며 특정 값을 표시하지 않으면 -5000 (임의의 센티넬 값)을 전달해야한다고 들었습니다. 그 이유는 Oracle 데이터베이스의 숫자 열이 (이전의) Oracle dev의 권장에 따라 null 값을 지원하지 않기 때문입니다. 이 회사는 또한 대부분의 코드를 VB6에 작성합니다 (느린 또 다른 주제 인 VB.NET으로 천천히 전환). 순수한 호기심으로이 권고에 대한 정당한 이유가 있습니까? 나는 내 편을 생각할 수 없다.

--- 편집하다

모든 의견에 감사드립니다. CodeProject.com ( link ) 에 동일한 질문을했으며 매우 유사한 피드백을 받았습니다. 이 방법이 외래 키와 관련이 있다는 것을 정당화하기 시작할 수있는 유일한시기이며 시스템의 어느 곳에서도 외래 키를 사용하지 않는다고 말할 수 있습니다. 이 결정을 내린 개발자 (저는 회사에서 근무 했었 음)가 나보다 훨씬 더 많은 경험을 가지고 있으므로, 사기가 발생하기 전에 이에 대한 정당한 이유가 없는지 확인하고 싶었습니다.

현실적으로 요구 사항은 미쳤다. 그러나 모든 위대한 미친 아이디어와 마찬가지로, 그것은 근본적인 이론적 근거를 이해하지 못하는 사람들에 의해 맥락에서 멀리 떨어진 잠재적 인 합리성의 너겟에 기초 할 것입니다.

NULL값이 허용 되지 않도록 데이터베이스 스키마를 설계하는 것이 합리적 일 수 있습니다 . 그러나 그렇게하면 필요하지 않은 모든 요소가 부모에 대한 적절한 외래 키 참조가 포함 된 별도의 테이블로 분할되는 정규화 수준으로 커밋됩니다. 실제로 실제로는 수행되지 않지만 수행해야 할 경우에는 이점이 있습니다.

NULL값이 허용 되지 않는 데이터베이스 스키마를 설계하려는 경우 , 무언가를 알 수 없다는 것을 나타 내기 위해 마술 값을 요구하는 것은 허용되지 않습니다. 그것은 NULL값 을 허용하는 모든 문제를 더하고 코드를 추가하여 모든 곳에서 반복되어야하는 마법의 값을 확인합니다. 데이터베이스 디자인에 관계없이 매직 값을 전달해야하는 API를 개발하는 것은 의미가 없습니다. 매직 값을 확인하여 코드를 복잡하게 만들려면 광기가 다른 시스템으로 전파되지 않도록해야합니다. .

NULL 대신 매직 값을 사용하는 유효한 이유가 없습니다 . 이것은 누군가 가이 혼란을 만드는 사고 과정 일 수 있습니다. 그들은 다음과 같이 씁니다.

 SELECT c1, c2 FROM t1 WHERE c3 < 30;

이것이 기대하는 결과를 반환하지 않으면 NULL을 포함하지 않으며 이것을 작성해야 함을 인식합니다.

SELECT c1, c2 FROM t1 WHERE c3 < 30 OR c3 IS NULL;

그들은 이것을 작성하기 위해 미래에 쓰거나 잊고 싶지 않기 때문에 모든 NULLS -5000을 만드는 해결책을 제시합니다. 마법의 원래 쿼리는 변경없이 NULL을 처리합니다. 그들이 깨닫지 못하는 것은 이제 이러한 가치를 배제하려는 사람이 이것을 써야한다는 것입니다.

SELECT c1, c2 FROM t1 WHERE c3 < 30 AND c3 <> -5000;

또는 이러한 값을 원하고 더 높은 범위를 검색하는 경우 :

SELECT c1, c2 FROM t1 WHERE c3 > 40 OR c3 = -5000;

또한 다음 사항이 더 이상 의미가 없다는 것을 인식하지 못할 수도 있습니다.

SELECT c1, c2 FROM t1 WHERE c3 IS NULL;

대신 사람은 마법의 가치를 기억해야합니다. 각 데이터 유형을 사용하면 1 / 1 // 1900, "Z", -5000과 같이 더 많은 마법 값을 기억해야합니다. 또한, 매직 값이 데이터에있을 때 다른 매직 값도 기억해야합니다.

따라서 특정 사례의 경우 디스크 공간, 인덱스 크기, 쿼리 구문 분석, 일관성 등을 언급하지 않고 다른 경우를 희생하여 코드를 더 간단하게 만듭니다.

완전 미치며 이에 대한 정당성이 없습니다. NULL값이 없음을 나타내고 & -5000과 같은 실제 값을 사용하기 위해 작성되었습니다.

일반적으로 나는이 짧은 대답을 쓰지 않을 것이지만 질문은 dba.se에서 가장 잘 보이는 것 중 하나 일 것입니다.

나는 이것에 대해 조금 긍정적으로 생각하고 null 대신 임의의 값을 사용해야 할 필요성을 정당화했으며 닫힌 데이터 마이닝 데이터 세트를 제외하고는 (적어도) 이것에 대한 정당한 이유가없는 것 같습니다 . 성능과 쿼리를 개선하고 단순화 한 다음 숫자가 데이터를 왜곡시킬 수있는 값이 아닌 경우에만 가능합니다. 이것조차도 신중하게 고려해야 할 것입니다. 모든 실제 상황에서 null 값을주는 것은 좋은 습관이 아닙니다. 이것은 사실이 아니기 때문에 NOT NULL 열 정의를 친구에서 적에게 바꿉니다.

우리의 응용 프로그램이 일부 (또는 모든) 열에 대해 NULL 값을 허용해서는 안된다는 것은 매우 다릅니다. 이것은 합리적이고 좋은 습관이며 널 (NULL)을 허용하지 않을 경우 문서화 된 이점이 있습니다 (예 : 키 및 색인 및 통계 계산). 그러나 널 (null)의 "자리에 앉아"값을 지정하는 것은 전혀 다릅니다. 결코 사용하지 않을 값을 먼저 선택하고, 널과 같이이 값을 필터링하고 계산 및 요약에 사용하지 말고 외부 데이터 피드에서 제거하지 않아야하므로이 값은 다시 작성해야합니다. . 실제 값을 나타 내기 위해 null을 사용하는 것은 적어도 나쁜 일입니다. 이것은 피하고 있다고 말하지만 그렇지 않습니다.

일단 이해되면 널 (null)로 인해 발생하는 대부분의 문제는 더 나은 정규화, 함수 기반 또는 비트 맵 인덱스 또는 간단한 WHERE x IS NOT NULL로 처리 할 수 ​​있습니다. 월간 성능 회의에서 일부 대규모 Telco 또는 Amazon에서 일부 DBA는 "null을 임의의 값, -5000과 같은 값으로 대체하여- 나는 가치에 열려있다 ... ". 또는 더 나은 응용 프로그램 디자인 사이에서 시간을 낭비하여 원치 않는 null을 필터링하고 주어진 실제 데이터를 하십니까? 좋아, 아마 월간 회의는 약간 낙관적이지만, 그들이 일어날 때마다 "더 나은 API를 위해 null을 -5000 (또는 무엇이든)으로 바꾸는 것은"의제 항목이 아니라는 것을 확신 할 수 있습니다.

나에게 누락 된 데이터 (연령 또는 가격 또는 지역 코드 또는 기타 코드가 있어야 함)를 허용하지 않는다고 말하는 것이 좋으며 때로는이 열에 대해 말하는 것이 좋습니다. 다른 것을 넣지 마십시오. 널을 의미하는 값을 따로 설정하는 것은 좋지 않습니다. 중간 이름 필드를 예로 들어보십시오. 부모가 모든 상자를 채우기에는 너무 게으 르기 때문에 때로는 존재하지 않을 것입니다. 검색을 개선하기 위해 데이터에 "없음"또는 "누락"또는 "알 수 없음"을 추가합니까? 이름을이 값으로 변경하는 이상한 사람들이있을 수 있으므로 데이터를 인쇄 할 때 데이터의 포함 여부를 모릅니다. 그것은 간단하지만 먼 예입니다. 우리는 NULL에 대해 알고 있으며이를 처리하기 위해 예측 가능한 내장 함수를 가지고 있습니다. 더 잘 코딩 할 수 없습니다.

응답이 없거나 입력 요청에 대한 올바른 응답이 아닌 경우 응용 프로그램이나 데이터베이스에서 응답을 허용하지 않으면 응답이 양호하면 응용 프로그램과 데이터베이스 모두에서 허용하고 처리해야합니다. 유효한 응답으로 유효한 응답 세트의 일부인 경우 데이터베이스를 저장하도록 설계해야합니다. 결국, 숫자 필드는 지루하므로 숫자를 얼룩으로 저장하고 야생 동물의 그림을 사용하여 각 숫자를 나타냅니다. 견과류 (시원하지만 견과류)이기 때문입니다. 우리는 또한 문자 B가 마음에 들지 않는다고 결정하지 않으며 잔인한 세서미 스트리트 악몽처럼 데이터에서 #으로 대체합니다. B가 응답이 아닌 경우 사용자에게 "여기에 B를 넣을 수 없습니다"라고 알려주십시오. 그렇다면 왜 널을 다르게 취급합니까?

따라서 응용 프로그램 수준에서 원하지 않는 null을 피하고 데이터베이스에서 처리하십시오. 기린 + 기린 = 하마처럼 무의미한 데이터 조정으로 인해 문제가 발생할 수 있습니다.