How do I implement a Voting system? - language-agnostic

I am required to implement a functionality similar to SO voting. I tried to look up some existing questions around this topic and noticed that most people are stuck with how to vote up and down. i am past that. my problem is related to how to handle after a vote has been upvoted. here is what i have done till now.
Vote up, Down and Score displayed for each answer.
Vote count changed when user clicks
up or down and the image is updated
accordingly.
Save the information in db like. who
voted, time of vote, type of vote,
userIP, ansID, etc.
Now the questions.
I am using a gridview to display information. how do i show the previously voted answers as voted on next page load. I have the information in db but i want to do this without affecting performance. I could do it in itemDatabound event but it doesnt look like a pretty way to handle it. i wonder if there is a better way to handle such situation
Toggle Votes : When a user toggles a
vote, what happens behind the
scenes. is the previous upvoted
record deleted or not? i say it
should be deleted but want a
confirmation.
Is gridview a good way to implement
such functionality or not?

For
1) If you are using a gridview you almost have to take this route. But we need more details about what you are trying to do.
2) When you upvote and then downvote that same answer / question it should be checked and deleted. Remember you are only allowed 1 vote for a question or answer so your database table should be written so that their is a unique row for a userID, a QuestionID (given that a question is unique). So you should not even allow it to insert duplicate rows in a table.
3)stackoverflow is mvc type app, you are using webforms, so you could use a gridview or a listview. They are probably just looping through the answers and generating the html (as this is MVC).

Related

Store lists/checklist into MySQL database

I want to make a demo application that is able to ask a user if he/she has followed the correct methods to build an item.
I have created a 'checklist' for the user to fill in as he/she builds the item. For example some of the questions could be:
Have you received the correct parts?
Are the parts in good condition?
Are you building a chair?
Do you have the correct specifications for the chair?
...
...
...
And so on...
So these questions have yes/no answers only. My plan was to create a table and call each column by the questions' number. So column 1 will be called '1' and it's the first question. Column 2 will be called '2' and it's the second question and so on.
So this table will be called Chair inspection. I then have another table called Table inspection with its own set of checklist questions.
This data is captured using an android application. The development of the application is done. Just need advice on the database part.
Is this the correct approach to storing the user's inputs?
I advice you have three tables, one for the questions, the other for the users who will be answering those questions and the last one is for the answers, then you establish the relationship between those three tables. That means Many users can answer many questions. Therefore there will be many to many relationship between users and questions. Then there will be relationship between questions and answers and answer with the users who responded to the questions.
I think that way you will be able to avoid redundancy and simplify the process of updating, and retrieving you data.
A normalised schema might be as follows (incomplete, and ignoring 'tables' for the time being) :
inspection
inspection_id* item inspected_by date
inspection_detail
inspection_id* checklist_id* status
* = (component of) PRIMARY KEY

Creating a Poll application. Need advice on database structure for the vote count

I'm writing an application to allow users to create a Poll. They ask a question and set n number of predefined answers to the question. Other users can vote on the answers provided for that question.
Current structure
I have designed the database like this:
Storing the vote count
Current thinking is, I create a new column called vote_count on the link table and every time that answer gets voted, it updates the record.
This works. But is it right? I'm new to database systems, so I can't imagine I'm doing much right. What are some more efficient ways to achieve this?
As far as it goes yes that's OK. However these tables will be incomplete. When your second quiz is created, you'll have to extend the QUESTIONS table. If this second quiz's Q1 also has a yes/no answer, you're going to have to extend the LINK/VOTES table.
You also have to think about how it's going to be queried and design indexes to support those queries.
Cheers -

database-design: table of likes?

I wonder,
at many websites there is the option to like/dislike a post.
even here of course, at stackoverflow.
so, technically it's a big likes table?
user_id post_id
user_id - who voted
post_id - which post is it
is that all about?
a big likes table?
isn't there something more efficient/sophisticated?
At it's most basic level, yes, that's all it is.
But then it starts to expand, trying to answer questions like:
How much did the user like this post?
When did they like the post?
How did they find the post?
Did they comment on the post?
How does the entire group/community like the post
Then you start to want to answer more in depth questions about friends and the community.
I think I can understand your concern. Having to issue a COUNT() everytime the page needs to be presented.
You certainly have to have this basic table, which will be the basis for a COUNT(), but you don't really need to COUNT() it for every access.
Create a totalling table and update it either when the page receives a like or dislike, using a trigger, or call a stored procedure to update it from time to time.
I would say each method is more indicated for different site personalities, ie, more readings or more writings, but you already know that when it comes to likes or dislikes nothing is previsible.

Simple survey database design

I'm creating a survey for visitors of my event.
However it's been a while since I created a database. So I need some help.
I found some solutions but they are way to extensive and that is something I don't need.
Visitors need to stay anonymous but they can leave their email behind (seperate table Emails that isn't linked to anything atm).
They have about 20 questions, some are open, some are one option(radio) and some are multiple options (checkboxes).
The questions need to be reusable.
That's about it.
I just don't know how to go beyond the many-to-many in the diagram you see below.
How do I go from here? An Answers table needs to have a relationship with? The Surveys_have_Questions, or with Questions?
Edit:
As the answer in the following links mentions, most surveys are based upon classic design patterns. Mine is one of those surveys. More info in the link below:
What mysql database tables and relationships would support a Q&A survey with conditional questions?
I would probably model the event of a user taking a survey, perhaps a table called "User_Answer_Session", which has links to the survey and the user; and then "User_Answers", which are tied to the session and the question and include the actual blob of the answer. How exactly I modeled the answers would depend on a few things (mainly how robustly I wanted to be able to look them up). For instance, do I want to be able to index multiple-choice answers for extremely rapid reporting? If so, then you need to model for that. This may include creating a "Question_Options" table, which is a one-to-many between a question and the available options...
This should get you thinking along a good path. :-)
well i dont see reason why you need all these tables ! i think it can be much simpler than that.
surverys
desc VarChar
startDate timestamp
endDate timestamp
isOpen boolean
survery_questions
survery_id int (FK)
question Text
vote_count unsigned INT
user_survery
user_id
survery_id
unique key (user_id_survery_id) #to ensure no duplicate votes
That all :).
when ever a user vote just run
insert into user_survery (user_id,survery_id) VALUES (1,1);
update survery_questions set vote_count = vote_count+1;
when u need to get a survery result
select * from survery_questions where survery_id = X;
etc.

MySql : how can I implement a sort of "read/not read yet" topics?

I'm about to implement a list of topic/argument in my forum, and I'd like to insert a sort of flag like "read/not read yet" for each message, regard each user in my website.
I think at somethings like this : a table watched_topics with id(INT), user(VARCHAR) and topic_id(INT). When a user watch the page, I'll insert (if the data doesn't exist) these information.
When another user will insert a new message in a topic, I'll delete from the table watched_topics all line with that topic_id.
That could provide a trouble : Think about to 9000 topics and 9000 users that have watched all topics : the table will be so big (9000x9000=81000000).
So, I think is not the best strategy to implement this kind of stuff! Any suggestion would be appreciated :)
Cheers
May I suggest a different approach?
Make use of web browser history mechanism.
Every topic can get a new, unique URL every time a new message is added there. It could include the number of messages, last modified time or a combination of both.
If the user did see the topic, he must have visited it, so a properly set up CSS can help identifying the read ones. You can even use some client-side scripts to modify the behaviour of the page based on that.
Another way to do that would be to keep the watched topics table the way you want to do it, but also store last visit time in user's profile and show all topics as read that haven't changed since that time.
However it's pretty safe to assume that all users reading all topics is very unlikely.
Your suggestion sounds good. I would make user-field also a foreign key - it gives you a bit more flexibility.
Are you sure all 9000 topics are read by all 9000 users? I mean is this reality? Like you said, topic-entries are deleted when new message is added. And when that happens, another 9000 entries are deleted :)
I would index the table and go with your suggestion (with user_id change). If the table size gets in your way, you can always change the implementation later. Most likely it will never be the issue anyway.
For the deletion: you could save what the latest msg-ID was the user saw. This way you do not have to perform a lot of delete actions every time a msg is posted in a much-viewed topic.