views:

731

answers:

12

Just browsing our db schema and found a field named 'IsFemale'

Is the name good, or is it kinda laughable?

+1  A: 

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!

marc_s
+24  A: 

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.

John Rasch
Never thought of that... very good point!
Lancelot
Whoever downvoted this is not very open-minded :)
John Rasch
Ooo enterprisey...we'll need to account for the Geno-mods in the 21st century too!
Mike Robinson
You forgot "File Not Found".
Ken
... my company's product has something like this in it. The choices are male, female, transgender male/female, transgender female/male, and something meaning asexual, thought the exact term for the last one eludes me at present.
rmeador
Perhaps you should refer to MOOs when coming up with a gender list: "LambdaMOO supports custom designations of gender, and comes with the following presets: neuter, male, female, either, Spivak, splat, plural, egotistical, royal, and 2nd-person" from http://en.wikipedia.org/wiki/LambdaMOO
Brian Campbell
You forgot 'desexed'. +1 anyway. =)
Evgeny
"Dear Sir and Madam" LMFAO! +1
Josh Stodola
You also need to consider Legal Entities, such as corporations. Certainly not male or female, but not both either.
Jeff Shattock
+6  A: 

Maybe naming the column "gender" (char with 'M', 'F') would me more "sensitive".

Vladimir
This is what I use, but not because it is more "sensitive." I use it because it is easier to read, uses just as much data space, and can be extended to support companies and hermaphrodites if necessary.
John Gietzen
@John - My chars must be bigger than yours...Mine like to stretch out and take up 8 bits. ;)
Mark Brackett
A: 

Gender seems a better choice, but if you want or need to use a boolean column, there are only two choices - IsMale or IsFemale.

Daniel Brückner
+1  A: 

What is wrong with the classic "sex" and supporting sub types such as M,F, etc...

DBAndrew
if you ever have to remove this column, then everyone will talk about "removing sex from our schema" :-)
Vladimir
Well, right now we're talking about whether we should have sex in the schema at all.
Chuck
+5  A: 

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).

vartec
To fix this, make it 1 character... of course that still leaves "Y" as an answer...
John Rasch
Hmmm. Would 'N' be "neuter" or "no"? Just thinking...
EricSchaefer
"twice a week"... lol... Both are good points, however.
Rui Craveiro
+3  A: 

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.

FlySwat
+44  A: 

You should stick with the ISO standard if at all possible.

JP Alioto
+1 - a serious answer!
John Rasch
My favorite line: "The standard explicitly states that no significance is to be placed on the fact that male is encoded as 1 and female as 2. The encoding merely reflects existing practice in the countries that initiated this standard." So unnecessarily politically correct
John Rasch
Nice. Didn't know about that one.
Mark Brackett
+1 interesting, I've never heard of that standard. In our database its male 1, female 0.
vartec
Great idea. Easily argumented, standardized behaviour! Didn't know about it either.
Joachim Sauer
@John: the "unnecessariry" can be argued about and depends a lot on the context, but the good thing is: the PC doesn't hurt here.
Joachim Sauer
So they don't handle "Transgendered" and "Neuter" yet? My colleagues will be disappointed. Or missing in joins, one or the other.
Meff
I can't believe there is a bloody ISO standard for this !
dr. evil
@Slough: even not believing in ISO standards has its own ISO standard!
Joachim Sauer
@Slough: There is an ISO standard for everything. Including proper use of salad forks. (Sporks were sadly left out but that's about the only thing that is)
epochwolf
@Meff: don't transgendered people typically pick one gender identity or the other?
Steven Huwig
@Meff, I guess that's what numbers 3-8 are for - various combinations/orientations. "Neuter" kind of made me laugh...
Andy White
crap, I never thought there can be a standard for this.
JPReddy
A: 

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.

Uri
+1  A: 

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.

rism
A: 

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.

adolfojp
+1  A: 

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.

Fabian
I think there's even a technical reason not to call it that. It's not a boolean field semantically. The question it tries to answer is (usually) not: "is this person female?", but rather the more general "what sex is this person?" And the answer to that is neither "true" nor "false".
Joachim Sauer
And: wouldn't giving *either* sex a preferred treatment make it non-PC ... err. ... non-value-neutral?
Joachim Sauer