[101008]

> Yeah, I think if they'd go as far to assume all women there (or all women past 30) have kids it would be pretty easy to assume any Doctor is a man.

Sadly true.

> But the use of strings for the gender field is excellent practice! Not only for non-binary gender(s) but also for "unknown" and any other edge cases.

I can see this option more popular nowadays due to the gender discussion, but how did they manage unknown back in the day if they used a boolean for this (I assume something like isMale or isFemale)?

[GuB-42]

In SQL it may be a NULL value, which has a weird logic but one that makes perfect sense here.

Otherwise, it can be represented as two booleans, one that tells if the gender is specified, and another one for the gender itself. Or it can be a 3 value enum, which is my preferred solution, even if we don't consider non-binary genders.

We should always consider the case when a field has no value. And I hope those who stored gender as a boolean did. Because what if you don't have that information? You can put a default (ex: male), but what if later, in another database, that person is explicitly female and you want to merge. You now have a conflict where you shouldn't.

[diarrhea]

For a third gender option of "unknown" you could extend the Boolean with FileNotFound, it's a classic trick really.

https://thedailywtf.com/articles/what_is_truth_0x3f_

[pdkl95]

https://web.archive.org/web/20170914014648/https://qntm.org/...