3 ms·

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 abs

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.

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.