3 ms·

> building database backed web applications where nils are simply unavoidable without some extreme over engineering or awkward idioms Say what? Adding a 'NOT

> building database backed web applications where nils are simply unavoidable without some extreme over engineering or awkward idioms Say what? Adding a 'NOT NULL' to your database fields is a no-brainer.

jacobsenscott 8y ago
Only for fields where a not null constraint makes sense of course. But NULL represents the absence of a value - which is very often a valid choice in a database.
- dragonwriter 8y ago
  > Only for fields where a not null constraint makes sense of course A NOT NULL constraint always makes sense, assuming your tables are designed correctly, such that each table contains all and only those columns needed to represent a distinct category of fact that needs to be stored, which necessarily means that all columns must occur together or not at all. When tables are designed instead to contain multiple different shapes of facts with some shared elements, then you get the need for nullable columns, but that's problematic in other ways, too.
  - jacobsenscott 8y ago
    Just because you can design a database that way doesn't mean you want to, or that you even have control over the db design. Anyway, data is still present or absent. Even if you have an address table where all the columns are not null you might not have an entry in that table for a user so what would you like user.address to return?
    - dragonwriter 8y ago
      > Even if you have an address table where all the columns are not null you might not have an entry in that table for a user so what would you like user.address to return? IMO, the best general solution is: if a relationship has a fixed cardinality of exactly one in the direction of interest, trying to traverse it should return the exactly one item it refers to. If a relationship has any other cardinality (fixed at some number > 1, variable between 0 and 1, variable between 0 and +∞, variable between 7 and 13, ...), trying to traverse it should return a container (set, bag, list, generator, ...) of values, whose cardinality will be the actual cardinality of the relationship. (That's really just as true if the underlying DB uses nulls or magic values or whatever else to indicate missing data; and, yes, returning application language nulls from low level database routines may be a convenience for those implementing the higher level abstraction layer on top of that low-level interface, but once you get into the mode layer there's not a great reason for presenting NULLs -- except in the special case of languages where the NULL is the empty list or another appropriate empty container.)
      - jacobsenscott 8y ago
        Yeah. I think the 0..1 case is cleaner as a nil/not nil vs a collection. The issue just doesn't go away. users.addresses.first&.street or whatever functional voodoo that buries if/else - users.addresses.map(&:street).first. You just end up switching empty/not empty list rather than nil/not nil. And the interface makes it look like a 0..n relationship which is super confusing for anyone not clued in to the pattern.

jacobsenscott 8y ago

Only for fields where a not null constraint makes sense of course. But NULL represents the absence of a value - which is very often a valid choice in a database.

dragonwriter 8y ago
> Only for fields where a not null constraint makes sense of course A NOT NULL constraint always makes sense, assuming your tables are designed correctly, such that each table contains all and only those columns needed to represent a distinct category of fact that needs to be stored, which necessarily means that all columns must occur together or not at all. When tables are designed instead to contain multiple different shapes of facts with some shared elements, then you get the need for nullable columns, but that's problematic in other ways, too.
- jacobsenscott 8y ago
  Just because you can design a database that way doesn't mean you want to, or that you even have control over the db design. Anyway, data is still present or absent. Even if you have an address table where all the columns are not null you might not have an entry in that table for a user so what would you like user.address to return?
  - dragonwriter 8y ago
    > Even if you have an address table where all the columns are not null you might not have an entry in that table for a user so what would you like user.address to return? IMO, the best general solution is: if a relationship has a fixed cardinality of exactly one in the direction of interest, trying to traverse it should return the exactly one item it refers to. If a relationship has any other cardinality (fixed at some number > 1, variable between 0 and 1, variable between 0 and +∞, variable between 7 and 13, ...), trying to traverse it should return a container (set, bag, list, generator, ...) of values, whose cardinality will be the actual cardinality of the relationship. (That's really just as true if the underlying DB uses nulls or magic values or whatever else to indicate missing data; and, yes, returning application language nulls from low level database routines may be a convenience for those implementing the higher level abstraction layer on top of that low-level interface, but once you get into the mode layer there's not a great reason for presenting NULLs -- except in the special case of languages where the NULL is the empty list or another appropriate empty container.)
    - jacobsenscott 8y ago
      Yeah. I think the 0..1 case is cleaner as a nil/not nil vs a collection. The issue just doesn't go away. users.addresses.first&.street or whatever functional voodoo that buries if/else - users.addresses.map(&:street).first. You just end up switching empty/not empty list rather than nil/not nil. And the interface makes it look like a 0..n relationship which is super confusing for anyone not clued in to the pattern.