I have a field in my database called "Gender".
When it is displayed on my web page, I want to show either "Male" or "Female".
For some strange reason, though, I am inclined to store things in my database as "M" or "F".
What should I do and why?
Robert
Full Version: Spell Out Gender?
Robert,
Depending on what sort of database this is, you could probably just store the gender as a boolean field, where True=Male and False=Female. Why? Because 99% of the time, there are only two choices to deal with, so there's no need to store more than a True/False value in your table. Then, in any query/form/report where you want to display the spelled-out version, you would just use a simple IF test:
=Iif(boolGender=True, "Male", "Female")
Now, this isn't the ONLY way to do things, and it's really not that critical. If you decide to only store "M" or "F", just set your field width to 1, and use a similar IF test when displaying the spelled out version:
=Iif(strGender="M", "Male", "Female")
Hope this helps,
Dennis
Depending on what sort of database this is, you could probably just store the gender as a boolean field, where True=Male and False=Female. Why? Because 99% of the time, there are only two choices to deal with, so there's no need to store more than a True/False value in your table. Then, in any query/form/report where you want to display the spelled-out version, you would just use a simple IF test:
=Iif(boolGender=True, "Male", "Female")
Now, this isn't the ONLY way to do things, and it's really not that critical. If you decide to only store "M" or "F", just set your field width to 1, and use a similar IF test when displaying the spelled out version:
=Iif(strGender="M", "Male", "Female")
Hope this helps,
Dennis
Hi Robert,
Assuming that your database is in Access, what version are you using? Please remember to select the version number when posting questions in case it becomes relevant to the discussion.
If you're asking how to do it in a query, then you could use an Iif() statement. If you're asking how to do it on your webpage, then we need to know what scripting language you are using.
Just my 2 cents...
Assuming that your database is in Access, what version are you using? Please remember to select the version number when posting questions in case it becomes relevant to the discussion.
If you're asking how to do it in a query, then you could use an Iif() statement. If you're asking how to do it on your webpage, then we need to know what scripting language you are using.
Just my 2 cents...
Robert,
Just a little add-on to the replies from doctor9 and theDBguy. I've done some on-line surveys and for things like Gender and Age, there's a "Prefer not to answer" response as well.
I don't know if this applies to your situation, but in addition to "Male" and "Female", there could also be "Prefer not to answer" and "No Answer."
AvgJoe
Just a little add-on to the replies from doctor9 and theDBguy. I've done some on-line surveys and for things like Gender and Age, there's a "Prefer not to answer" response as well.
I don't know if this applies to your situation, but in addition to "Male" and "Female", there could also be "Prefer not to answer" and "No Answer."
AvgJoe
Reminds me of the college building at the University of Massachusetts years ago: the lecture rooms were named after the counties in the state.
On the second floor there was a lobby with three doors - "Men" on the left, "Women" on the right, and "Middlesex" between.
On the second floor there was a lobby with three doors - "Men" on the left, "Women" on the right, and "Middlesex" between.
QUOTE (theDBguy @ May 3 2012, 01:03 PM) 
Hi Robert,
Assuming that your database is in Access, what version are you using? Please remember to select the version number when posting questions in case it becomes relevant to the discussion.
If you're asking how to do it in a query, then you could use an Iif() statement. If you're asking how to do it on your webpage, then we need to know what scripting language you are using.
Just my 2 cents...
Assuming that your database is in Access, what version are you using? Please remember to select the version number when posting questions in case it becomes relevant to the discussion.
If you're asking how to do it in a query, then you could use an Iif() statement. If you're asking how to do it on your webpage, then we need to know what scripting language you are using.
Just my 2 cents...
Oops, this would be in MySQL.
And the essence of my questions was, "Can I stored the final formatted versions that I want for Gender in the database, or should I stick with a 0/1 or M/F value and then have to code every place I need to display things"
It seems smarter to me to store things as "Male/Female" and then when I want to display it I would just have...
CODE
<?php
echo "<dl>
<dt>Gender:</dt>
<dd>$gender</dd>
</dl>";
?>
echo "<dl>
<dt>Gender:</dt>
<dd>$gender</dd>
</dl>";
?>
See where I am going with this?
For display purposes, that seems like a better approach.
But maybe for Queries or Analysis it is better to use a binary field?!
Robert
If you do use a true/false field do not use Access's Yes/No data type unless you want to misconstrue every null value for an assertion of sex.
Trivial,
It is possible to set a default value of either True or False for a boolean field.
Robert,
You could always use a User Defined Function to translate the boolean value to text:
Now all you "have to do" is use GenderText(boolGender) to display the text version.
Hope this helps,
Dennis
It is possible to set a default value of either True or False for a boolean field.
Robert,
QUOTE
and then have to code every place I need to display things
You could always use a User Defined Function to translate the boolean value to text:
CODE
Public Function GenderText(boolGender as Boolean) as String
If boolGender=True Then
GenderText = "Male"
Else
GenderText = "Female"
End If
End Function
If boolGender=True Then
GenderText = "Male"
Else
GenderText = "Female"
End If
End Function
Now all you "have to do" is use GenderText(boolGender) to display the text version.
Hope this helps,
Dennis
QUOTE (doctor9 @ May 3 2012, 02:17 PM)
You could always use a User Defined Function to translate the boolean value to text:
Now all you "have to do" is use GenderText(boolGender) to display the text version.
Hope this helps,
Dennis
CODE
Public Function GenderText(boolGender as Boolean) as String
If boolGender=True Then
GenderText = "Male"
Else
GenderText = "Female"
End If
End Function
If boolGender=True Then
GenderText = "Male"
Else
GenderText = "Female"
End If
End Function
Now all you "have to do" is use GenderText(boolGender) to display the text version.
Hope this helps,
Dennis
Just goes to show you what a light-weight I am!!
(Haven't really gotten comfortable writing my own functions yet, but that is a good example!)
Thank you,
Robert
Robert,
to expand on a point from my first post... this isn't really a critical decision to make. Unless your database has tens of thousands of people in it, I doubt if you would see a big change in processing time/storage one way or another.
Once you get comfy with your first few functions, you'll wonder how you lived without them. I can't count how many incredibly complex IF statements I had in textbox controlsources before I figured out how to do UDF's...
Dennis
to expand on a point from my first post... this isn't really a critical decision to make. Unless your database has tens of thousands of people in it, I doubt if you would see a big change in processing time/storage one way or another.
Once you get comfy with your first few functions, you'll wonder how you lived without them. I can't count how many incredibly complex IF statements I had in textbox controlsources before I figured out how to do UDF's...
Dennis
QUOTE (doctor9 @ May 3 2012, 02:48 PM)
Robert,
to expand on a point from my first post... this isn't really a critical decision to make. Unless your database has tens of thousands of people in it, I doubt if you would see a big change in processing time/storage one way or another.
to expand on a point from my first post... this isn't really a critical decision to make. Unless your database has tens of thousands of people in it, I doubt if you would see a big change in processing time/storage one way or another.
Yeah, I may wimp out for now and just go with "Male/Female".
QUOTE
Once you get comfy with your first few functions, you'll wonder how you lived without them. I can't count how many incredibly complex IF statements I had in textbox controlsources before I figured out how to do UDF's...
Dennis
Dennis
I am eager to get into more advanced concepts like that, but my brain is overflowing right now trying to learn web development!!
For the most part, I am trying to stick with simpler - even if longer - code and getthings working, and then I can go back and look for common bits of code and refactor and do fancier things like you are recommending!
I am also being slightly more cautious, because things are different on the web - as I keep finding out.
Things that were EASY to do in MS Access are quite a bit trickier in PHP (e.g. passing values between web pages). So that is one reason why I am not ready for Functions on the web yet. I need to get more comfortable with variable scope, passing values, includes, etc before I start stream-lining my code.
Thanks for the help, though!
Robert
>> And the essence of my questions was, "Can I stored the final formatted versions that I want for Gender in the database, or should I stick with a 0/1 or M/F value and then have to code every place I need to display things" <<
Neither. Create a Domain Table (aka: Lookup table) ...
tblGenders
-------------
GenderId (primary index key, typically an Autonumber ... but could be text or just a number the sysadmin enters)
Gender
Then have a Foreign Key field in tables that have an attribute that requires gender. By doing this, you allow for changing times with respect to what gender is (Male, Female, Transgender-Female, Transgender-Male, etc.) plus it allows you to react to polital correctness if Male or Female is suddenly deamed inappropriate because you can change the name gender of Male to XY and since the Foreign Key relates to the GenderId, you have saved a ton of time by not having to modify your code base to react to the changing times.
Also, by using the Domain Table concept, you and leave your Foreign Key fields as Null if the gender is unknown.
With the Domain Table concept, you now don't have to calculate anything when you display your data, you simply JOIN the tblGenders table on a match between the foreign key and primary key of GenderId, then place the tblGenders.Gender field in the Select clause of your query.
>> For some strange reason, though, I am inclined to store things in my database as "M" or "F". .... What should I do and why? <<
By the way, the phrasing of your topic starting post sounds an awful lot like a question a student would get on an assignment ... is this for something similar? The reason I ask is that our approach to reply's to students may yeild different pieces of information since the mode of learning has slightly different motivations --- that is not saying students don't get help, I am just saying that replies might force some deeper thought.
Neither. Create a Domain Table (aka: Lookup table) ...
tblGenders
-------------
GenderId (primary index key, typically an Autonumber ... but could be text or just a number the sysadmin enters)
Gender
Then have a Foreign Key field in tables that have an attribute that requires gender. By doing this, you allow for changing times with respect to what gender is (Male, Female, Transgender-Female, Transgender-Male, etc.) plus it allows you to react to polital correctness if Male or Female is suddenly deamed inappropriate because you can change the name gender of Male to XY and since the Foreign Key relates to the GenderId, you have saved a ton of time by not having to modify your code base to react to the changing times.
Also, by using the Domain Table concept, you and leave your Foreign Key fields as Null if the gender is unknown.
With the Domain Table concept, you now don't have to calculate anything when you display your data, you simply JOIN the tblGenders table on a match between the foreign key and primary key of GenderId, then place the tblGenders.Gender field in the Select clause of your query.
>> For some strange reason, though, I am inclined to store things in my database as "M" or "F". .... What should I do and why? <<
By the way, the phrasing of your topic starting post sounds an awful lot like a question a student would get on an assignment ... is this for something similar? The reason I ask is that our approach to reply's to students may yeild different pieces of information since the mode of learning has slightly different motivations --- that is not saying students don't get help, I am just saying that replies might force some deeper thought.
QUOTE (datAdrenaline @ May 3 2012, 03:37 PM)
>> And the essence of my questions was, "Can I stored the final formatted versions that I want for Gender in the database, or should I stick with a 0/1 or M/F value and then have to code every place I need to display things" <<
Neither. Create a Domain Table (aka: Lookup table) ...
tblGenders
-------------
GenderId (primary index key, typically an Autonumber ... but could be text or just a number the sysadmin enters)
Gender
Then have a Foreign Key field in tables that have an attribute that requires gender. By doing this, you allow for changing times with respect to what gender is (Male, Female, Transgender-Female, Transgender-Male, etc.) plus it allows you to react to polital correctness if Male or Female is suddenly deamed inappropriate because you can change the name gender of Male to XY and since the Foreign Key relates to the GenderId, you have saved a ton of time by not having to modify your code base to react to the changing times.
Neither. Create a Domain Table (aka: Lookup table) ...
tblGenders
-------------
GenderId (primary index key, typically an Autonumber ... but could be text or just a number the sysadmin enters)
Gender
Then have a Foreign Key field in tables that have an attribute that requires gender. By doing this, you allow for changing times with respect to what gender is (Male, Female, Transgender-Female, Transgender-Male, etc.) plus it allows you to react to polital correctness if Male or Female is suddenly deamed inappropriate because you can change the name gender of Male to XY and since the Foreign Key relates to the GenderId, you have saved a ton of time by not having to modify your code base to react to the changing times.
Sad, but valid points. (When I was growing up "Men where men"!!)
QUOTE
Also, by using the Domain Table concept, you and leave your Foreign Key fields as Null if the gender is unknown.
With the Domain Table concept, you now don't have to calculate anything when you display your data, you simply JOIN the tblGenders table on a match between the foreign key and primary key of GenderId, then place the tblGenders.Gender field in the Select clause of your query.
With the Domain Table concept, you now don't have to calculate anything when you display your data, you simply JOIN the tblGenders table on a match between the foreign key and primary key of GenderId, then place the tblGenders.Gender field in the Select clause of your query.
Except two issues with that...
1.) I am doing this on the web, and those design decisions probably don't make as much sense as they do in MS Access.
2.) Most enterprise-level database developers I have known shy away from "Lookup Tables" because they don't scale well. That and they much up your database quick with hundreds of un-needed tables.
QUOTE
>> For some strange reason, though, I am inclined to store things in my database as "M" or "F". .... What should I do and why? <<
By the way, the phrasing of your topic starting post sounds an awful lot like a question a student would get on an assignment ... is this for something similar? The reason I ask is that our approach to reply's to students may yeild different pieces of information since the mode of learning has slightly different motivations --- that is not saying students don't get help, I am just saying that replies might force some deeper thought.
By the way, the phrasing of your topic starting post sounds an awful lot like a question a student would get on an assignment ... is this for something similar? The reason I ask is that our approach to reply's to students may yeild different pieces of information since the mode of learning has slightly different motivations --- that is not saying students don't get help, I am just saying that replies might force some deeper thought.
I am almost in my 50's!!! *LMAO*
No, you are not helping me do my homework?!
I am just anal-retentive, and I decided to go down the rabbit hole and open up the debate or "0/1" vs "M/F" vs "Male/Female".
Clearly there are pros and cons of each way.
Just figured I would refresh my rusty database mind, and see if I was forgetting a more accepted approach.
Robert
QUOTE (robert_trace @ May 3 2012, 06:00 PM)
Sad, but valid points. (When I was growing up "Men where men"!!)
I am right there with you ...
QUOTE (robert_trace @ May 3 2012, 06:00 PM)
Except two issues with that...
1.) I am doing this on the web, and those design decisions probably don't make as much sense as they do in MS Access.
2.) Most enterprise-level database developers I have known shy away from "Lookup Tables" because they don't scale well. That and they much up your database quick with hundreds of un-needed tables.
1.) I am doing this on the web, and those design decisions probably don't make as much sense as they do in MS Access.
2.) Most enterprise-level database developers I have known shy away from "Lookup Tables" because they don't scale well. That and they much up your database quick with hundreds of un-needed tables.
I respectfully disagree. There is no substitute for good database design and if you need a table, then you simple need a table. I am an enterprize-level database developer and I do not shy away from Domain Tables (aka: lookup tables ... please don't confuse that with lookup fields in the Table object designer of Access). The key is to develop Views that return the information you want to present, then with the disconnected nature of data these days, your page code can write changes back to the source tables, if your web page offers edits to the data.
QUOTE (robert_trace @ May 3 2012, 06:00 PM)
I am almost in my 50's!!! *LMAO*
No, you are not helping me do my homework?!
I am just anal-retentive, and I decided to go down the rabbit hole and open up the debate or "0/1" vs "M/F" vs "Male/Female".
No, you are not helping me do my homework?!
I am just anal-retentive, and I decided to go down the rabbit hole and open up the debate or "0/1" vs "M/F" vs "Male/Female".
I am getting there quickly! ... and always learning! ... thanks for clearing things up! ...
you old man <cough, sputter, ... where did I put my glasses #$%$%)&(*)> QUOTE (robert_trace @ May 3 2012, 06:00 PM)
Clearly there are pros and cons of each way.
Most definately! ... Plus, you are the one designing and maintaining your system, so what you do is entirely up to you! --- like you really need to be told that eh?
QUOTE (datAdrenaline @ May 3 2012, 04:14 PM)
I respectfully disagree. There is no substitute for good database design and if you need a table, then you simple need a table. I am an enterprize-level database developer and I do not shy away from Domain Tables (aka: lookup tables ... please don't confuse that with lookup fields in the Table object designer of Access). The key is to develop Views that return the information you want to present, then with the disconnected nature of data these days, your page code can write changes back to the source tables, if your web page offers edits to the data.
Okay, I'll consider that.
QUOTE
I am getting there quickly! ... and always learning! ... thanks for clearing things up! ... you old man <cough, sputter, ... where did I put my glasses #$%$%)&(*)>
you old man <cough, sputter, ... where did I put my glasses #$%$%)&(*)> Ha ha
QUOTE
Most definately! ... Plus, you are the one designing and maintaining your system, so what you do is entirely up to you! --- like you really need to be told that eh?
At least not from some young whipper-snapper like yourself...
(Every time I think I am done, I go off and ponder things that really don't mean much - like how do they hold sesame seeds on the buns?! - and waste an entire day online chatting and debating?! UGH!!
Of well, at least no one can accuse me of not being thorough!!)
Thanks for the insight.
Robert
QUOTE (robert_trace @ May 3 2012, 12:47 PM)
It seems smarter to me to store things as "Male/Female" and then when I want to display it I would just have...
CODE
<?php
echo "<dl>
<dt>Gender:</dt>
<dd>$gender</dd>
</dl>";
?>
echo "<dl>
<dt>Gender:</dt>
<dd>$gender</dd>
</dl>";
?>
Just a thought...
CODE
<?php
function getGender($sex)
{
if ($sex=="M")
{
return "Male";
}
else
{
return "Female";
}
}
echo "<dl>
<dt>Gender:</dt>
<dd>".getGender($gender);."</dd>
</dl>";
?>
function getGender($sex)
{
if ($sex=="M")
{
return "Male";
}
else
{
return "Female";
}
}
echo "<dl>
<dt>Gender:</dt>
<dd>".getGender($gender);."</dd>
</dl>";
?>
(untested)
Just my 2 cents...
I would store the gender as Number (Byte).
1 for Male and -1 for Female.
No code is required.
The display of the text is managed by the Format Property of the control where it is displayed.
Four alternative text strings can be displayed for positive, negative, zero and Null values respectively.
Separate them with semicolons like this.
"Male";"Female";"Intersex";"Not Entered"
Colours can also be nominated.
"Male"[blue];"Female"[red];"Intersex"[green];"Not Entered"
1 for Male and -1 for Female.
No code is required.
The display of the text is managed by the Format Property of the control where it is displayed.
Four alternative text strings can be displayed for positive, negative, zero and Null values respectively.
Separate them with semicolons like this.
"Male";"Female";"Intersex";"Not Entered"
Colours can also be nominated.
"Male"[blue];"Female"[red];"Intersex"[green];"Not Entered"
Hello Galaxiom,
>> I would store the gender as Number (Byte).
1 for Male and -1 for Female. <<
Not possible --
-- Number/Byte is from 0 to 255 inclusive. For that strategy, you'd need Number/Integer
>> The display of the text is managed by the Format Property of the control where it is displayed.
Four alternative text strings can be displayed for positive, negative, zero and Null values respectively.
Separate them with semicolons like this. <<
I beleive the topic starter had indicated this design is for the web (assuming the meaning was for a web page ... not an A2010 web database), so the Format property likely will not apply to this circumstance.
>> I would store the gender as Number (Byte).
1 for Male and -1 for Female. <<
Not possible --
-- Number/Byte is from 0 to 255 inclusive. For that strategy, you'd need Number/Integer>> The display of the text is managed by the Format Property of the control where it is displayed.
Four alternative text strings can be displayed for positive, negative, zero and Null values respectively.
Separate them with semicolons like this. <<
I beleive the topic starter had indicated this design is for the web (assuming the meaning was for a web page ... not an A2010 web database), so the Format property likely will not apply to this circumstance.
Well spotted re the Byte, Brent. I didn't think long enough there.
I hadn't actually read the thread about where it would be applied. The thread seemed to drift off a bit.
Using the format property is good if you can. I haven't tested it thoroughly but it seems faster than lookups and Conditional Formatting.
It works with a textbox instead of requiring a combo but of course it is limited to four ranges of values and they have to be numbers.
Also works in the table but probably falls into the same evil category as table level lookups.
I am pretty sure it predates Conditional Formatting which largely supersceded the colour functionality so it is a little obscure now.
It is a good idea to note it somewhere in the form's module as a reminder.
I remember scratching my head for a while when there was no conditional format on a control yet it behaved like there was.
It was my own database design too. I had just forgotten I used it.
I hadn't actually read the thread about where it would be applied. The thread seemed to drift off a bit.
Using the format property is good if you can. I haven't tested it thoroughly but it seems faster than lookups and Conditional Formatting.
It works with a textbox instead of requiring a combo but of course it is limited to four ranges of values and they have to be numbers.
Also works in the table but probably falls into the same evil category as table level lookups.
I am pretty sure it predates Conditional Formatting which largely supersceded the colour functionality so it is a little obscure now.
It is a good idea to note it somewhere in the form's module as a reminder.
I remember scratching my head for a while when there was no conditional format on a control yet it behaved like there was.
It was my own database design too. I had just forgotten I used it.
ISO/IEC-5218 Codes for Gender (by ISO's Data Management and Interchange Technical Committee)
Thanks Richard for pulling the topic on track.
This - the ISO/IEC 5218 standard - also solves the issue with people of gender X, the "transverts" (don't know the exact English word).
/gustav
This - the ISO/IEC 5218 standard - also solves the issue with people of gender X, the "transverts" (don't know the exact English word).
/gustav
QUOTE (doctor9 @ May 3 2012, 04:17 PM)
Trivial,
It is possible to set a default value of either True or False for a boolean field.
It is possible to set a default value of either True or False for a boolean field.
However it is not possible to set a default value to neither true nor false, hence my comment: Yes/No fields misconstrue null data for assigned data(Specifically "No" by default).
This can be problematic if you are ever in a position where you do not know a person's sex at the time of data entry. Null data shows up in the set of "No" answers which means you cannot (for example) query to correct at a later date when you have more information. If you want to query workforce count by gender you will have an inflated "No" set (by default).
http://allenbrowne.com/noyesno.html
Looking over this once again I see another reason which I have not encountered: Outer join queries.
I personally use a lookup/domain table. That is certainly not the only option though.
ed:
Gustav - In English it is "Transgender" or "Trans(s)exual" depending on what you're discussing. The condition under discussion is Gender Dysphoria if you'd like to read up on it.
Trivial,
I stand by my statement, whether you think it's a good idea or not is another thing entirely. I've used boolean fields with default values for over ten years with zero problems.
Dennis
I stand by my statement, whether you think it's a good idea or not is another thing entirely. I've used boolean fields with default values for over ten years with zero problems.
Dennis
<Brent>
I like your approach, but you left out "Hermaphroditic"... and "neuter"...
I like your approach, but you left out "Hermaphroditic"... and "neuter"...
QUOTE (doctor9 @ May 4 2012, 11:18 AM)
Trivial,
I stand by my statement, whether you think it's a good idea or not is another thing entirely. I've used boolean fields with default values for over ten years with zero problems.
Dennis
I stand by my statement, whether you think it's a good idea or not is another thing entirely. I've used boolean fields with default values for over ten years with zero problems.
Dennis
The ability to set default values to a boolean field has not been questioned.
There is no epistemic difference between a default value of male and a default value of female. They are both equally likely to be false or true.
Our actual disagreement (if we in fact have one, which I suspect we do not) is over this question: Do people have a default gender? My position is that they do not.
All else is fluff. The conclusions you are obligated to draw follow logically and self evidently from this point.
Trivial,
Ah, you're right we don't really have a disagreement. I misunderstood the point you were trying to make.
My intial post mentioned "99% of the time". I conced that there are cases where you will want to store something besides M or F - but since the person who started this thread hasn't indicated that this is a possibility yet, I'm assuming it's not an issue.
Dennis
QUOTE (Trivial @ May 4 2012, 11:33 AM)
Our actual disagreement (if we in fact have one, which I suspect we do not) is over this question: Do people have a default gender? My position is that they do not.
Ah, you're right we don't really have a disagreement. I misunderstood the point you were trying to make.
My intial post mentioned "99% of the time". I conced that there are cases where you will want to store something besides M or F - but since the person who started this thread hasn't indicated that this is a possibility yet, I'm assuming it's not an issue.
Dennis
robert - this is getting similar to your other thread
this all comes down to how you describe your data.
in your system if M/F is suffcient to describe the entire population, you can with a boolean, or you could use a letter or number. personally, i prefer booleans for such attributes.
if you need more than 2 options, then you need to go with a letter or number.
personally, i would generally use a numeric. i would also make this a lookup value in another table to provide the actual description corresponding to the selected value.
the decision about the number of states required is an analysis decision. the implementation is a design decision
in the same way, choosing to display text values for the sex, or just using a tick box, is an implementation decision
however - i would personally use a lookup table for multiple text values. otherwise
a) you open up the possibility for erroneous text valyes to be entered
b) long text fields take up more data storage, and are less efficient than numbers.
this all comes down to how you describe your data.
in your system if M/F is suffcient to describe the entire population, you can with a boolean, or you could use a letter or number. personally, i prefer booleans for such attributes.
if you need more than 2 options, then you need to go with a letter or number.
personally, i would generally use a numeric. i would also make this a lookup value in another table to provide the actual description corresponding to the selected value.
the decision about the number of states required is an analysis decision. the implementation is a design decision
in the same way, choosing to display text values for the sex, or just using a tick box, is an implementation decision
however - i would personally use a lookup table for multiple text values. otherwise
a) you open up the possibility for erroneous text valyes to be entered
b) long text fields take up more data storage, and are less efficient than numbers.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.