If you follow a separate-tables approach, you can process the choices separately, and independently, in most cases, simply by iterating over the individual tabl

If you follow a separate-tables approach, you can process the choices separately, and independently, in most cases, simply by iterating over the individual tables. So the choice is indeed largely eliminated. In the majority of cases you're only interested in one of the choices, or are following links that point to instances of a specific known choice. So, no switching code there. > you have to test the value for not being null Don't assume possibility of null if it's not a valid value in your data schema. There are so many codebases rotten by never ending null checks. There are no benefits from them, and only drawbacks: They confuse the reader by checking for a situation that should never happen, giving the impression it could be a valid situation. (This is actually a point the OP makes). Let me exaggerate a little bit. Superfluous null checks are similar to something like def add(int x, int y) -> int: return x + y int z = add(1, 2) if z != 3: return 0 else: return 3 Just because it's "possible" that z is not 3 because there are other values that are also integers, that doesn't mean you have to cover them. Type systems are much less helpful than many FP advocates want you to think, and if you depend too much on them you get a bad, bad codebase (and you deserve it). The main benefits that type systems bring: 1) they catch your typos early, 2) they support compilation to efficient machine code. If you use tables and indexes, there are no pointers and no null anyway. Then again, I've used -1 as a sentinel in the past, and there are many more unused negative values available if you need them :-)