Analysis: Poll 2005
A key problem with our poll is that it does not track any information about who voted, which means that it is difficult to obtain peripheral information from it. For example, consider a members-only movie site where people joined by filling in a form with their name, address, age, and gender. Once they logged in, they could vote for their favourite film, favourite genre, favourite actor/actress, etc. Using Poll v2, we could say with certainty that 2000 votes were case in favour of Indiana Jones being the best film, but we couldn't say that those 2000 votes were not cast by the same person. Furthermore, despite knowing quite a lot about each person voting, we couldn't tell what they voted for, which is not taking advantage of the demographic information stored about them (name, age, etc).
Wouldn't it be good if we could stop people from voting twice, while at the same time being able to produce results like "98% of people who voted for Indiana Jones were male"? Getting these kind of meaningful results is not possible without individually tracking each vote as it came in, and that requires further normalisation - we need to split the answers from the answer votes, thereby creating three tables (question, answers, and votes cast).
From the end user perspective, this should look exactly the same as before, except that a user attempting to vote for a poll a second time will have their vote discounted with a warning message.
We're not going to cover the actual creation of a user authentication system here - you will have to do that yourself. For the purposes of this creation we're going to assume user ID 22 for all user-related information, so you will need to replace that number with your user code wherever you see it.
So, we have three database tables and two files. Here is how the tables look from a conceptual view:
Next chapter: Making the final poll >>
Previous chapter: Putting Poll v2 into action
Home: Table of Contents