4 ms·

In the end, you'll have a mixture of NULL and "" in your DB, and a couple of years later a piece of logic written in another language will fail spectacularly.

• jflwyasdf 3y ago
  This is how I would do it. Go: *string Java: Option<String> or @Nullable String Rust: Option<String> TypeScript: string | undefined (or string | null)
  • golergka 3y ago
    The problem is, not all of these languages think that "" and null are equal.
    • codebje 3y ago
      I might choose to rephrase that as "the problem is, some of these languages think that "" and null are equal." :-)
      • goatlover 2y ago
        Isn't the lack of strict equality a result of loose typing in those languages?
        • codebje 2y ago
          Maybe - often more to do with overeager coercion, which does tend to go hand in hand with loose typing.
• skissane 3y ago
  One response to this is issue is a CHECK constraint LENGTH(column) > 0, so you can’t have empty strings. Rarely do you have a textual database column where the empty-vs-NULL distinction is semantically meaningful in the application domain. Most of the time, either the column value is missing (arguably better represented by NULL) or has a non-blank value. “Present but blank” is rarely meaningful or useful Sometimes I pair that with (TRIM(column)=column) to prevent leading or trailing whitespace being saved, which also stops all-blank values being saved This works really well if you have an RDBMS which supports CREATE DOMAIN, so then you can attach these constraints to a user-defined type and don’t have to repeat them for each column, you just set the type of the column to that user-defined type
• codebje 3y ago
  It took many years to eliminate all the instances of "NULL" from the database.
• lmz 2y ago
  > In the end, you'll have a mixture of NULL and "" in your DB Not if you use Oracle.