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.
Related
I am building a simple social networking website (a personal project of mine to help me understand back-end programming more) and as of the moment I am stuck on how I should tackle the above problem.
Right now I have a table for users, posts, comments, replies, post_likes, comment_likes and reply_likes.
As of the moment my system works as follows:
A user creates a post which will then be inserted to the posts table along with that user's id
Whenever a user comments on said post, a row is inserted into the comments table along with the user's id and the post's id
Whenever a user replies to a comment, it is inserted into the replies table together with that user's id as well as the comment's id in which the reply was made
Enter my likes tables which is structured as so...
post_likes
post_id
user_id
like_state
comment_likes
comment_id
user_id
like_state
reply_likes
reply_id
user_id
like_state
You can probably already tell where I am going with this, but each time a user likes a certain post, comment or reply it gets inserted into its respective like table along with that user's id and a like_state to prevent them from liking again.
This all works fine but I am clearly repeating myself which I know is taboo in the programming world. Which leads us to my question, what exactly can I do to remedy this? Although I came up with an idea, I just can't quite figure out how I can structure my question well enough to be able to get any good results from Google (I am not a native English speaker)
PS the solution I came up with is simply creating just one likes table and each row could either have just a post_id (if the user liked a post), a comment_id (if the user liked a comment) or a reply_id (if the user liked a reply), is that possible?
I think your current tables are good. I think your post, comments and replies has a one to many relationship with the likes. The like should go in separate tables. And you are exactly doing that. If you want to combine the likes into one table, then you will need an extra column to track what is belongs to what. And you will also not able to set the foreign key constrain on that table. So, IMO, you are good at this point.
Is it a good idea to store like count in the following format?
like table:
u_id | post_id | user_id
And count(u_id) of a post?
What if there were thousands of likes for each post? The like table is going to be filled with billions of rows after a few months.
What are other efficient ways to do so?
In two words answer is : yes , it is OK. (to store data about each like any user did for any post).
But I want just to separate or transform it to several questions:
Q. Is there other way to count(u_id)? or even better:
SELECT COUNT(u_id) FROM likes WHERE post_id = ?
A. Why not? you can save count in your post table and increase/decrease it every time when user like/dislike the post. You can set trigger (stored procedure) to automate this action. And then to get counter you need just:
SELECT counter FROM posts WHERE post_id = ?
If you like previous Q/A and think that it is good idea I have next question:
Q. Why do we need likes table then?
A. That depends of your application design and requirements. According to the columns set you posted : u_id, post_id, user_id (I would even add another column timestamp). Your requirements is to store info about user as well as about post when it liked. That means you can recognize if user already liked this post and refuse multilikes. If you don't care about multilikes or historical timeline and stats you can delete your likes table.
Last question I see here:
Q. The like table is going to be filled with billions of rows after a few months. isn't it?
A. I wish you that success but IMHO you are 99% wrong. to get just 1M records you need 1000 active users (which is very very good number for personal startup (you are building whole app with no architect or designer involved?)) and EVERY of those users should like EVERY of 1000 posts if you have any.
My point here is: fortunately you have enough time till your database become really big and that would hurt your application. Till your table get 10-20M of records you can do not worry about size and performance.
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 -
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.
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).