Timeline for Is there a compelling reason why columns in SQL are nullable by default?
Current License: CC BY-SA 3.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 10, 2017 at 23:06 | comment | added | Jules | ... and I think this is the point behind excluding NULLs from 'D'. NULL isn't easily definable on a global level, because there are so many choices like those that have to be decided upon. Giving the user the tools to easily create types that contain placeholder values, and decide for themselves how those placeholders should work, is a much more useful practice, and can avoid a lot of trouble later. | |
| Nov 10, 2017 at 23:05 | comment | added | Jules | @nocomprende - perjaps. But when so many subtle (or not subtle) bugs are caused by nulls behaving in a different way to the way the programmer expects (or even a different way to the way the standard specifies, a source of errors that plagued MySQL developers for many, many years...), I kind of get his point. There are a lot of different ways NULL could behave, and this leaves you often not being sure how it will behave. Does NULL == NULL? Is the sum of a column that contains a null a value (ignoring the NULL) or is the result NULL? Are rows with NULLs and identical non-NULLs distinct? | |
| Nov 8, 2017 at 14:49 | comment | added | user251748 | Codd said that there should be more types of Null, I think he proposed 4 initially and later expanded to 17. Programmers said: Why are we wasting effort distinguishing ways of saying "I don't know"? Sure, there are known unknowns, and unknown unknowns, but really, data is the known known, and not much else. | |
| Nov 8, 2017 at 13:57 | comment | added | Philip Couling | @PieterB Yes and no. The fundamental problem of null is that it is used to mean too many different things. In SQL it could mean "doesn't exist" or it could mean "unknown". The D argument is that these should all be distinctly defined and a catch-all "null" should never be used. Not having studied it in detail, I suspect that proponents of D would advocate Not Present = Not Present where in SQL neither null = null or null != null are true. | |
| Nov 8, 2017 at 13:45 | comment | added | Pieter B | @jules what's the conceptional difference between an int-field being nullable and an int-field having an alternative datatype: 'not present'? Isn't it the same thing with a different name? Null is also an alternative datatype to int. | |
| Nov 8, 2017 at 12:27 | comment | added | Philip Couling | My first comment is hard to follow so I'll put it simply: Representing x with null is a bad idea Does not infer that allowing x by default is bad. Ergo it does not imply that allowing null by default is bad where null is the only available representation of x | |
| Nov 8, 2017 at 12:20 | comment | added | Philip Couling | I don't follow / don't agree with your logic. I believe you are conflating two separate issues. Issue a) should a language represent null at all? Issue b) in a language that does use null to mean "not-present" should fields allow null (not-present) by default? Perhaps you've missed a step in your answer... Is there an item c) In D, attributes must not allow not-present by default because .... <insert argument here> | |
| Nov 8, 2017 at 11:21 | history | answered | Jules | CC BY-SA 3.0 |