When making a database with users (that have attributes such as religion), what is the best way to store those attributes and the possible values for them?
Here are the methods and problems:
method 1: If you have a user, say a Christian, you could store this value in the users table under a column called "Religion". The problem with this method is that there would be many, many occurences of the word "Christian" in the users table, which seems redundant to me.
problem 1: Also, with this method, there is nowhere in the database that all possible values are stored like "Buddhist", "Muslim", etc. This would make populating a dropdown difficult if not impossible.
method 2: Another method I came up with is to index these values. Change the "Religion" column in the users table to "ReligionID" and number them. Christian = 1, Muslim = 2, etc. Then have a foreign key relationship to another table with the lookup values.
problem 2: The problem with this method is that there will have to be many, many tables linked to the users table with foreign key values for other similar attributes, like eye color. Although populating a dropdown list would be easy with this method, this seems to create too many joins and seems like an ugly way to design this database.
What is the best way to do this? Feel free to come up with your own methods if these ones are not optimal. Thanks!
database normalization is all about tradeoffs. The way I look at it, I always start with as close to 3nf as possible (ie. method 2). When either the size of my data, or my performance requirements change ... I consider denormalizing (ie. method 1).
when you get to that point, your applications need to take responsibility for data integrity ... depending on how much control you have over the clients of the database, that may or may not be easy. But that's why you get paid the big bucks ;-)