Just browsing our db schema and found a field named 'IsFemale'
Is the name good, or is it kinda laughable?
Just browsing our db schema and found a field named 'IsFemale'
Is the name good, or is it kinda laughable?
Are you only ever going to have to check for "IsFemale" true/false?
Wouldn't a column like "PersonType" or something like that be more appropriate? That way, you could have "female", "male", "company" and so forth - more possible values.
Marc
PS: but if you choose to use a "bit" (boolean) column, then the "Is" or "Has" prefix is a good choice, in my opinion - makes it quite clear it's a boolean!
Female and male are not mutually exclusive, so you'll have to come up with something for transsexuals, unisex, etc.
To make this as enterprisey as possible, create a GenderTypeID
column:
GenderTypes
-----------
GenderTypeID Name Greeting
1 Male Dear Sir
2 Female Dear Madam
3 Unisex Dear Sir and Madam
4 Unknown Dear Sir or Madam
5 Android Dear Artificial Life Form
... and so on.
Maybe naming the column "gender" (char with 'M', 'F') would me more "sensitive".
Gender
seems a better choice, but if you want or need to use a boolean column, there are only two choices - IsMale or IsFemale.
What is wrong with the classic "sex" and supporting sub types such as M,F, etc...
Well, the typical thing is to have "sex" column, but you may end up with clueless clients trying filing it with values as "twice a week".
Other problem is that it's language dependent. For example in English M will mean Man, while in Spanish it may mean Mujer (woman).
isFemale indicates a bigger problem with your schema, something like that should be generalized, or possibly even normalized out:
Like, having a sex column on your table, which is a FK to a sex table:
---------------------
| ID | Type |
|-------------------|
| 1 | Male |
| 2 | Female |
| 3 | Yes Please |
---------------------
Note, don't actually do this, its silly, unless you plan supporting unusual genders. I still think a generic column is better than a isFemale bit though.
If you're asking if it's laughable, that depends. Would isMale be better, you chauvinist? (Just kidding!)
My guess is that whoever designed the database thought of special business rules for females and designed it this way.
There really isn't a reason why male should be true and female should be false, and it is possible that your database is less efficient in using a character and character comparison.
From a programming point of view, avoiding booleans in tables make sense for the same reasons that avoiding booleans in function parameters makes sense.
Every database I've ever worked with has used a column name of Gender with values 0 for Female and 1 for Male. I've always assumed these values were assigned in much the same way that electronics equipment has connectors that are described as being female or male.
Whether or not IsFemale is laughable depends on the intent of the system, however it does seem to have painted the application into a corner. Gender fields for instance can be grown to accommodate additional "type" but IsFemale is obviously only ever going to be true or false and therefore not at all extensible.
For simple systems where there is no sexual ambiguity I use IsMale. The alternative would be to use a lookup table if your requirements include intersexed individuals. If you only have males and females, using anything other than a boolean value introduces unnecessary complexity and ambiguity to the system.
It is clear the questioner is concerned (rightly) about the failure of the database designer to take into account value-neutral language.
(Please be aware that politically correct is (rightly) no longer considered accepted, value-neutral language.)
As a computer designer, you have a particular obligation to ensure your designs do not, inadvertantly or not, include or propagate gender-preference or superiority.
While the designer may have naively presumed IsFemale would give females a 1 and therefore higher/superior value, true values are often given the value of -1. Not to mention cultures where 0 is a sacred value.
In next week's installment, we'll cover people who are intersex and queer theory and its implications for variable naming standards.