누락 된 데이터를 나타내는 데 NULL 대신 'Z'를 표준 적으로 사용합니까?

누락 된 데이터를 나타내는 데 NULL 대신 'Z'를 표준 적으로 사용합니까?

---

NULL이 사용되어야하는지 여부에 대한 인수 외에는 "누락되거나 입력되지 않은"데이터를 의미하기 위해 NULL을 사용하는 기존 데이터베이스에 대한 책임이 있습니다. "사용자가이 값을 설정하고 '비어 있음'을 선택했습니다."라는 의미의 빈 문자열과 다릅니다.

프로젝트의 또 다른 계약자는 "NULL은 나를 위해 존재하지 않는다. 나는 NULL을 절대 사용하지 않으며 다른 누구도 그렇게해서는 안된다"라는 주장에 확고하게 동의합니다. 그러나 저를 혼란스럽게하는 것은 계약 업체의 팀이 "누락 / 입력 한 적이 없음"과 "의도적으로 비어 있거나 사용자가 알 수 없음으로 표시 한 것"의 차이를 인정하기 때문에 코드 및 저장 프로 시저 전체에서 단일 문자 'Z'를 사용하여 데이터베이스의 나머지 부분에서 NULL과 동일한 의미로 "누락 / 입력하지 않음"을 나타냅니다.

우리의 공유 고객이이 변경을 요청했고 내가이 요청을 지원했지만 팀은이를 저보다 훨씬 더 진보 된 DBA들 사이에서 "표준 관행"으로 인용합니다. 그들은 내 무지한 요청만으로 NULL을 사용하도록 변경하는 것을 꺼립니다. 그래서 누구든지 내 무지를 극복하도록 도울 수 있습니까? NULL 대신 'Z'사용을 옹호하는 SQL 전문가들 사이에 표준 또는 소규모 개인 그룹 또는 단일 큰 목소리가 있습니까?

최신 정보

추가 할 계약자의 응답이 있습니다. 고객이 데이터가없는 열에서 NULL을 허용하기 위해 특수 값을 제거하도록 요청했을 때 다음과 같이 말했습니다.

기본적으로 가능한 한 NULL을 피하도록 데이터베이스를 설계했습니다. 근거는 다음과 같습니다.

• 빈 (길이가 0 인) 문자열이 정확히 동일한 정보를 제공하므로 문자열 [VARCHAR] 필드에 NULL이 필요하지 않습니다.

• 정수 필드의 NULL (예 : ID 값)은 데이터에서 발생하지 않는 값 (예 : 정수 IDENTITY 필드의 경우 -1)을 사용하여 처리 할 수 ​​있습니다.

• 날짜 필드의 NULL은 날짜 계산에서 쉽게 복잡해질 수 있습니다. 예를 들어 [RecoveryDate]와 [OnsetDate] 사이의 날짜 차이와 같은 날짜 차이를 계산하는 논리에서 두 날짜에 대해 명시 적으로 허용하지 않는 한 하나 또는 두 날짜가 모두 NULL이면 논리가 파열됩니다. NULL입니다. 그것은 추가 작업과 추가 처리입니다. "기본"또는 "자리 표시 자"날짜가 [RecoveryDate] 및 [OnsetDate] (예 : "1/1/1900")에 사용되는 경우 수학적 계산에 "비정상적인"값이 표시 될 수 있지만 날짜 논리는 확장되지 않습니다.

NULL 처리는 전통적으로 개발자가 저장 프로 시저에서 실수하는 영역이었습니다.

DBA로 15 년 동안 저는 가능한 한 NULL을 피하는 것이 가장 좋다는 것을 알게되었습니다.

이것은이 질문에 대한 대부분의 부정적인 반응을 입증하는 것 같습니다. NULL을 설계하는 데 허용 된 6NF 접근 방식을 적용하는 대신 특수 값을 사용하여 "가능한 경우 항상 NULL을 방지"합니다. 나는 열린 마음으로이 질문을 올렸고, "NULL은 유용하다 / NULL은 사악하다"논쟁에 대해 더 많이 알게되어 기쁘지만, 이제는 '특별한 가치'접근 방식을 완전히 넌센스로 분류하는 것이 매우 편안합니다.

빈 (길이가 0 인) 문자열은 정확히 동일한 정보를 제공합니다.

아니요, 그렇지 않습니다. 수정중인 기존 데이터베이스에서 NULL은 "입력하지 않음"을 의미하고 빈 문자열은 "비어 있음으로 입력 됨"을 의미합니다.

NULL 처리는 전통적으로 개발자가 저장 프로 시저에서 실수하는 영역이었습니다.

예,하지만 이러한 실수는 수천 명의 개발자에 의해 수천 번 발생했으며 이러한 실수를 방지하기위한 교훈과주의 사항이 알려져 있고 문서화되어 있습니다. 여기에서 언급했듯이 NULL을 허용하든 거부하든 누락 된 값의 표현은 해결 된 문제 입니다. 개발자가 극복하기 쉬운 (그리고 식별하기 쉬운) 실수를 계속하기 때문에 새로운 솔루션을 발명 할 필요가 없습니다.

---

각주 : 저는 20 년 넘게 DBE 및 개발자로 일했습니다 (데이터베이스 엔지니어와 데이터베이스 관리자의 차이점을 알기에 충분한 시간입니다). 내 경력 내내 나는 항상 "NULL은 유용하다"캠프에 있었지만, 몇몇 매우 똑똑한 사람들이 동의하지 않는다는 것을 알고있었습니다. 나는 "특별한 가치"접근 방식에 대해 극도로 회의적 이었지만 "올바른 방법으로 NULL을 피하는 방법"의 학자에 대해서는 확고한 입장을 제시 할만큼 충분히 정통하지 않았습니다. 저는 항상 새로운 것을 배우는 것을 좋아합니다. 그리고 20 년이 지난 후에도 여전히 배울 것이 많습니다. 이 토론을 유용한 토론으로 만드는 데 기여한 모든 분들께 감사드립니다.

---

계약자를 해고하십시오.

좋아요, 진지하게, 이것은 표준 관행이 아닙니다. 이것은 내가 작업 한 모든 RDBMS가 NULL, NULL에 대한 논리를 구현하고, 외래 키에서 NULL을 고려하고, COUNT에서 NULL에 대해 다른 동작을 갖기 때문에 간단히 볼 수 있습니다.

나는 실제로 'Z'또는 다른 자리 표시자를 사용하는 것이 더 나쁘다고 주장합니다. 'Z'를 확인하려면 여전히 코드가 필요합니다. 그러나 'Z'는 'Z'를 의미하는 것이 아니라 다른 것을 의미한다는 것을 문서화해야합니다. 그리고 그러한 문서를 반드시 읽어야합니다. 그렇다면 'Z'가 유효한 데이터가되면 어떻게 될까요? (이니셜 필드 등?)

기본 수준에서 NULL 대 'Z'의 유효성에 대해 토론하지 않더라도 계약자가 회사가 아닌 회사 내에 존재하는 표준 관행을 준수한다고 주장합니다. 대체 표준 관행이있는 환경에서 그의 표준 관행을 도입하면 혼란, 유지 관리 오버 헤드, 오해가 발생하고 결국 비용과 실수가 증가합니다.

---

편집하다

내 의견으로는 NULL 대신 사용할 수있는 경우가 있습니다. 그러나 그렇게하는 경우에만 설명이 필요한 특수 사례를 생성하는 대신 코드를 줄일 수 있습니다.

예를 들어 날짜 제한 데이터에 사용했습니다. 시작 날짜와 종료 날짜 사이에 데이터가 유효하면 NULL 값이 없어 코드를 단순화 할 수 있습니다. 대신 NULL 시작 날짜를 '01 Jan 1900 '으로 바꾸고 NULL 종료 날짜를 '31 Dec 2079'로 바꿀 수 있습니다.

이것은 여전히 ​​예상되는 동작을 변경할 수 있으므로주의해서 사용해야합니다.

• WHERE end-date IS NULL 더 이상 유효한 데이터를 제공하지 않습니다.
• 방금 천년기 버그를 만들었습니다.
• 기타

이는 모든 속성이 항상 유효한 값을 가질 수 있도록 추상화를 재구성하는 것과 같습니다. 특정 의미를 임의로 선택한 값으로 암시 적으로 인코딩하는 것과는 현저하게 다릅니다.

그래도 계약자를 해고하십시오.

---

이것은 내가 들어 본 것 중 가장 이상한 의견 중 하나입니다. NULL이 아닌 "데이터 없음"을 나타내는 매직 값을 사용하면 보유한 모든 코드가 "데이터 없음"/ "Z"값을 고려 / 삭제하기 위해 결과를 후 처리해야합니다.

NULL은 데이터베이스가 쿼리에서 처리하는 방식 때문에 특별합니다. 예를 들어 다음 두 가지 간단한 쿼리를 사용합니다.

select * from mytable where name = 'bob';
select * from mytable where name != 'bob';

경우 name지금까지 NULL이, 그것은 분명 첫 번째 쿼리의 결과에 표시되지 않습니다. 더 중요한 것은 두 번째 쿼리 결과에 표시되지 않는다는 것입니다. NULL은 다음과 같이 명시적인 NULL 검색 이외의 다른 항목과 일치하지 않습니다.

select * from mytable where name is NULL;

그리고 데이터가 Z를 유효한 값으로 가질 수 있다면 어떻게 될까요? 누군가의 중간 이니셜을 저장한다고 가정 해 보겠습니다. Zachary Z Zonkas는 중간 이니셜이없는 사람들과 함께 할 수 있을까요? 아니면 계약자가 이것을 처리 할 또 다른 마법의 가치를 생각해 낼까요?

데이터베이스가 이미 완전히 처리 할 수있는 코드에서 데이터베이스 기능을 구현해야하는 마법의 값을 피하십시오. 이것은 해결되고 잘 이해 된 문제이며, 계약 업체가 NULL 개념을 전혀 이해하지 못했기 때문에이를 사용하지 않기 때문일 수 있습니다.

---

If the domain allows missing values, then using NULL to represent 'undefined' is perfectly OK (that's what it is there for). The only downside is that code that consumes the data has to be written to check for NULLs. This is the way I've always done it.

I have never heard of (or seen in practice) the use of 'Z' to represent missing data. As to "the contractor cites this as 'standard practice' among DBAs", can he provide some evidence of that assertion? As @Dems mentioned, you also need to document that 'Z' doesn't mean 'Z': what about a MiddleInitial column?

Like Aaron Alton and many others, I believe that NULL values are an integral part of database design, and should be used where appropriate.

---

Even if you somehow manage to explain to all your current and future developers and DBAs about "Z" instead of NULL, and even if they code everything perfectly, you will still confuse the optimizer because it will not know that you've cooked this up.

Using a special value to represent NULL (which is already a special value to represent NULL) will result in skews in the data. e.g. So many things happened on 1-Jan-1900 that it will throw out the optimizer's ability to understand that actual range of dates that really are relevant to your application.

This is like a manager deciding: "Wearing a tie is bad for productivity, so we're all going to wear masking tape around our necks. Problem solved."

---

I've never heard about the wide-spread use of 'Z' as a substitute for NULL.

(Incidentally, I'd not particularly like to work with a contractor who tells you in the face that they and other "advanced" DBAs are so much more knowledgeable and better than you.)

 +=================================+
 |  FavoriteLetters                |
 +=================================+
 |  Person      |  FavoriteLetter  |
 +--------------+------------------+
 |  'Anna'      |  'A'             |
 |  'Bob'       |  'B'             |
 |  'Claire'    |  'C'             |
 |  'Zaphod'    |  'Z'             |
 +---------------------------------+

How would your contractor interpret the data from the last row?

Probably he would choose a different "magic value" in this table to avoid collision with the real data 'Z'? Meaning you'd have to remember several magic values and also which one is used where... how is this better than having just one magic token NULL, and having to remember the three-valued logic rules (and pitfalls) that go with it? NULL at least is standardized, unlike your contractor's 'Z'.

I don't particularly like NULL either, but mindlessly substituting it with an actual value (or worse, with several actual values) everywhere is almost definitely worse than NULL.

Let me repeat my above comment here for better visibility: If you want to read something serious and well-grounded by people who are against NULL, I would recommend the short article "How to handle missing information without using NULLs" (links to a PDF from The Third Manifesto homepage).

---

Nothing in principle requires nulls for correct database design. In fact there are plenty of databases designed without using null and there are plenty of very good database designers and whole development teams who design databases without using nulls. In general it's a good thing to be cautious about adding nulls to a database because they inevitably lead to incorrect or ambiguous results later on.

I've not heard of using Z being called "standard practice" as a placeholder value instead of nulls but I expect your contractor is referring to the concept of sentinel values in general, which are sometimes used in database design. However, a much more common and flexible way to avoid nulls without using "dummy" data is simply to design them out. Decompose the table such that each type of fact is recorded in a table that doesn't have "extra", unspecified attributes.

---

In reply to contractors comments

• Empty string <> NULL
• Empty string requires 2 bytes storage + an offset read
• NULL uses null bitmap = quicker
• IDENTITY doesn't always start at 1 (why waste half your range?)

The whole concept is flawed as per most other answers here

---

While I have never seen 'Z' as a magic value to represent null, I have seen 'X' used to represent a field that has not been filled in. That said, I have only ever seen this in one place, and my interface to it was not a database, but rather an XML file… so I would not be prepared to use this an argument for being common practice.

Note that we do have to handle the 'X' specially, and, as Dems mentioned, we do have to document it, and people have been confused by it. In our defence, this is forced on us by an external supplier, not something that we cooked up ourselves!

참고URL : https://stackoverflow.com/questions/6638291/standard-use-of-z-instead-of-null-to-represent-missing-data