[I can't respond to your comment directly. This is a bit off-topic, but I think it's interesting!! Here goes.] > It is true that "not all men are the same" (an

[I can't respond to your comment directly. This is a bit off-topic, but I think it's interesting!! Here goes.] > It is true that "not all men are the same" (and "not all women are the same"), but splitting into "trans male" and "trans female" is probably more accurate than lumping all "trans people" into one category. > After all, it would be silly to have only 2 chategories "trans" and "cis" (trans:cis :: gay:straight). My original post was in jest—in fact, it was inspired by some holy-crap-I-can't-believe-it's-real database schema I've had to work with. Someone made an effort to hyper-normalize things and saddled us with a disaster: Every query required seven or eight slow joins, and there was duplicate data sprinkled everywhere (in my example, the same patient could inadvertently have records in both the Male and Female tables). The "architect" quit a few weeks after it went to production. Anyway, I consider (biological) "sex" to be a sliding scale: one end being female, the other end being male, and the middle being intersex. I consider (social) "gender" to be where one self-identifies on that scale. Others might disagree, but I think this is a useful distinction. Upon reflection, it's obvious that my schema isn't even remotely helpful! My inclusion of the "Transgendered" table implied that the three tables were genders, not sexes. Gender, being a self-identified trait, has nothing to do with whether one can get pregnant. So if we wanted to hyper-normalize our schema and indicate that only certain patients can get pregnant, we should clearly have a "Uterus" table. In fact, it would probably be wise to have tables for every body part, and inner-join on all of them whenever we need to grab a patient's information. Or we could use check constraints... but our schema diagrams would be much less impressive.