3 ms·

What it means is that you have an awfully named column. >NULL means I couldn't store a value in that column. Why? Well that depends on the system, just like th

by Retra 11y ago

What it means is that you have an awfully named column. >NULL means I couldn't store a value in that column. Why? Well that depends on the system, just like the contents of every other column. No, it means you stored a NULL value in that column. Why you did that rather than throwing an error or generating a more informative value is a mystery. And it is not made clearer by changing the name of your column. And someone writing code to handle that data can't know how to handle it, because they have no clue what went wrong, or even if it is wrong.

wvenable 11y ago
> Why you did that rather than throwing an error or generating a more informative value is a mystery. Why would you think it's automatically an error or that a more informative value could exist? I might have a form with yes/no or date answers and if a question isn't required and the user doesn't provide an answer then it's stored as NULL. Either way the meaning is obvious, it's read and written perfectly fine, and it's not an error. I don't understand the implication that storing NULL means something went wrong? That's not at all what it means to me. I'm going to assume something about your response: you seem to conflating the concept of stored null value in database vs. returning a null reference or pointer in C.
- Retra 11y ago
  NULL could mean "not applicable", in which case it is not an error. Or it could mean "unknown" in which case it is a data inconsistency. It could mean "not available", in which case it is a signal. It could mean "uninitialized data", in which case it is a process error. There's no way to programmatically determine which of these cases it is. >I don't understand the implication that storing NULL means something went wrong? It doesn't mean something went wrong. It also doesn't mean something went right. It means nothing by itself. NULL simply has no consistent semantics in a DB model. Its only semantic purpose is to make joins consistent, which often has nothing to do with your problem domain. That's why higher levels of normalization tend toward fewer uses of NULL. Imagine you were using a database to log processes on a supercomputer. You log access to the machine whenever a process starts, and you write a NULL value to the end_time field for the process. What does NULL mean, here? Does it mean the process is still running? Or does it mean the process failed to write it's end state (for instance, if the machine crashed?) Does it mean the process is non-terminating? If you read this value from the database, would it be correct to wait for the process to finish? You'd have to go and look at what processes are running. Which means this field no longer models the end time of the process, it models some dirty hybrid thing that you have to manually verify every time you read a NULL value. That's the problem with NULLs: they are bad at modeling your domain. It's a big middle finger from your data telling you to verify it yourself. It is one of those things that makes computers stupid, because you can't get past it without involving a human brain. (Which would make it very hard to make a computer learn how to build database schemas.)
  - wvenable 11y ago
    > There's no way to programmatically determine which of these cases it is. There is no need to programmatically determine which case it is. You're way over thinking the problem. > NULL simply has no consistent semantics in a DB model. Yes, it's the lack of a value. If you have an end_time field and you don't have an end_time and column doesn't allow NULLs, what do you put in there? It's a simple question. If you put any kind of valid value in there (which you have to do) then you'll be wrong. > Or does it mean the process failed to write it's end state (for instance, if the machine crashed?) You sure as hell better be using transactions to maintain consistency. This has nothing to do with the problem. If you do it this way that's just wrong. Has nothing to do with nulls. If you had a perfectly non-null FLAG you'd have the same problem. > Which means this field no longer models the end time of the process While the process is running it doesn't have an end_time, so what do you put in this field?
    - Retra 11y ago
      >There is no need to programmatically determine which case it is. Thank you for saying the dumbest thing I've heard all week. This conversation is over.
      - wvenable 11y ago
        Or should I say, there is no greater burden to what NULL means for a specific column than any other value. You didn't answer my questions, I'm disappointed but not surprised. Since you can't simply provide a valid value for when one doesn't make sense -- you need NULL for those cases, it's unavoidable.

by Retra 11y ago

wvenable 11y ago

> Why you did that rather than throwing an error or generating a more informative value is a mystery. Why would you think it's automatically an error or that a more informative value could exist? I might have a form with yes/no or date answers and if a question isn't required and the user doesn't provide an answer then it's stored as NULL. Either way the meaning is obvious, it's read and written perfectly fine, and it's not an error. I don't understand the implication that storing NULL means something went wrong? That's not at all what it means to me. I'm going to assume something about your response: you seem to conflating the concept of stored null value in database vs. returning a null reference or pointer in C.

Retra 11y ago
NULL could mean "not applicable", in which case it is not an error. Or it could mean "unknown" in which case it is a data inconsistency. It could mean "not available", in which case it is a signal. It could mean "uninitialized data", in which case it is a process error. There's no way to programmatically determine which of these cases it is. >I don't understand the implication that storing NULL means something went wrong? It doesn't mean something went wrong. It also doesn't mean something went right. It means nothing by itself. NULL simply has no consistent semantics in a DB model. Its only semantic purpose is to make joins consistent, which often has nothing to do with your problem domain. That's why higher levels of normalization tend toward fewer uses of NULL. Imagine you were using a database to log processes on a supercomputer. You log access to the machine whenever a process starts, and you write a NULL value to the end_time field for the process. What does NULL mean, here? Does it mean the process is still running? Or does it mean the process failed to write it's end state (for instance, if the machine crashed?) Does it mean the process is non-terminating? If you read this value from the database, would it be correct to wait for the process to finish? You'd have to go and look at what processes are running. Which means this field no longer models the end time of the process, it models some dirty hybrid thing that you have to manually verify every time you read a NULL value. That's the problem with NULLs: they are bad at modeling your domain. It's a big middle finger from your data telling you to verify it yourself. It is one of those things that makes computers stupid, because you can't get past it without involving a human brain. (Which would make it very hard to make a computer learn how to build database schemas.)
- wvenable 11y ago
  > There's no way to programmatically determine which of these cases it is. There is no need to programmatically determine which case it is. You're way over thinking the problem. > NULL simply has no consistent semantics in a DB model. Yes, it's the lack of a value. If you have an end_time field and you don't have an end_time and column doesn't allow NULLs, what do you put in there? It's a simple question. If you put any kind of valid value in there (which you have to do) then you'll be wrong. > Or does it mean the process failed to write it's end state (for instance, if the machine crashed?) You sure as hell better be using transactions to maintain consistency. This has nothing to do with the problem. If you do it this way that's just wrong. Has nothing to do with nulls. If you had a perfectly non-null FLAG you'd have the same problem. > Which means this field no longer models the end time of the process While the process is running it doesn't have an end_time, so what do you put in this field?
  - Retra 11y ago
    >There is no need to programmatically determine which case it is. Thank you for saying the dumbest thing I've heard all week. This conversation is over.
    - wvenable 11y ago
      Or should I say, there is no greater burden to what NULL means for a specific column than any other value. You didn't answer my questions, I'm disappointed but not surprised. Since you can't simply provide a valid value for when one doesn't make sense -- you need NULL for those cases, it's unavoidable.