We have both. Zero and Null are different data types.
For context, NULL/missing was a type. N/A was a type (i.e. a question irrelevant to someone). I can't remember the 3rd, and of course not the additional (4th or 5th) type he was proposing. If anyone knows a good resource that describes this problem domain, that would be much appreciated. I've been haunted for over 20 years by the regret of not fully appreciating what he was trying to explain to me, both because I could've learned something that day, but also because I almost immediately felt like an a*hole for not showing enough interest in and respect for a piece of scholarly work he was clearly proud of and wanted to share with me.
EDIT: I think the third pre-existing type was for a situation where someone abstains from answering a question like, "Sex: male/female", because they consider themselves neither. So something like an Other type. In retrospect this was presumably related to set theory, and he felt there was a gap in the pre-existing formal models.
“Don’t know”: this has a value, but we do not know it could be one. Also, within N/A, one _could_ discriminate between “not available yet”, “will never be available”, “was available once, but was lost”, etc.
Depending on the domain, others could be
- “Can’t tell”: this has a value, but you are not allowed not know it (unlikely, as you likely also shouldn’t be allowed that the value exists)
- incomputable: this has a value, but it isn’t possible to know it
I think generic systems shouldn’t try to capture such domain specific things, but allow for implementing them. SQL shouldn’t even have null, but have enums and product types on top of which you could create it and functions supporting it.
NI No Information - the default, it is unknown and why it is unknown is also unknown
UNK Unknown - the most common other than NI
ASKU Asked but Unknown
NASK Not Asked - we don't know because we didn't ask
MSK Masked - hidden due to privacy or legal etc
NA Not Applicable
NAV Not Available - for example patient might be unconscious or doctor might be unreachable, temporary
> SQL shouldn’t even have null
But it needs to, because it needs to represent half of a result record not existing, i.e. on a LEFT JOIN.
But you can imagine two kinds of "don't care" values, too: the complacent one, and the assertive one. The complacent one is the one we have in Karnaugh maps, which says, "it doesn't matter what I am, so if it matters to you what I am, I'll be what you want". But the assertive variant says, "I don't matter, and if I matter for your calculation, your calculation clearly doesn't matter either."
It’s common for surveys to encode various null values. ‘Refused to answer’, ‘Did not know’, ‘Not applicable’, ‘Illegible response’ etc, although there is no standard way to do this.
The SAS language allows you to use multiple custom missing values, but this is not widely known and I’ve never seen anyone do it.