I'm not a database guy, but am attempting to cleanup another database. So my real question is would normalizing the gender table go too much?
User table: userid int pk, genderid char(1) fk etc... gender table: genderid char(1) pk, gender varchar(20)
Now in the beginning it appeared silly in my experience, however I considered it because i'm able to then possess a constant databases to populate from or bind from. I'll be using WPF. Whether it was another framework I'd most likely cure it, but what is your opinion?
Whether you decide to normalize your table structure to accomodate gender will rely on the needs of the application as well as your business needs.
I'd normalize if:
- You need to have the ability to manage the "description" of the gender within the database, and never in code.
- This enables you to definitely rapidly alter the description from Guy/Lady to Male/Female, for instance.
- The application presently must handle, or will possible handle later on, localization needs, i.e. having the ability to specify gender in various languages.
- Your company mandates that everything be stabilized.
I wouldn't normalize if:
- You've got a easy application where one can easily manage the description from the gender in code instead of within the database.
- You've tight programmatic charge of the information going interior and exterior the gender area such that you could ensure consistency from the data for the reason that area.
- You simply worry about the gender area for information capture, meaning, you do not have lots of programmatic have to update this area once it's set the very first time.
I am also not really a database guy however i get it done. It provides me with the chance to make sure that just the genders are joined, which are valid (referencial integrity) and I'm also able to utilize it to populate the choice control.
Only use a little. for male, 1 for female. Normalizing this to some research table only is sensible should you intend on adding "other. "
See also this post.
I'm able to think about programs where I'd use different posts for sex and gender, have three values for sex (male/female/decline to condition) and six for gender (male/female/transgendered male/transgendered female/asexual/decline to condition). Granted, My home is Bay Area, where there's an degree of public discussion of transgender problems that a lot of the relaxation around the globe is behind the bend on.
The thing is: with no compelling reason to consider otherwise, I'd think that any simplifying assumption I made about census was limited and parochial. The price of breaking sex to its very own table is small now and costly later. I would not steer clear of the small cost based on a belief.
Well, your organization may have essential that, if at all possible, everything be stabilized.
Also, with respect to the business &lifier data, you will need to incorporate transgenders too which may create 3+ genders (I'm not sure the number of you will find, haven't checked)
I'll remark on another aspect: sorting. Normally, 'M' sorts after 'F' inside a project once, a database table were built with a gender area with either of individuals two values. There is a need to have the ability to sort results around the gender (census data) along with a further preference to possess 'M' appear before 'F'. My solution ended up being to give a separate research table, setting a mans value an ID of , and feminine an ID of just one. So queries around the primary table could be easily sorted around the new genderID area.