I am looking to created a voting system for my site. I am having a little trouble deciding on how to model it.
At present I have models like so:
Group has many users
On each group page it will have the same question, for example:
"What feature would you like next?"
Each group would have a the same set of answers which can be voted on. I am going to use the Thumbs Up gem to allow answers to be voted on.
The amount of groups is extremely large, somewhere in the region of 5000.
I was thinking about modelling it like so:
Answer has many Responses
Response belongs to Group, Answer and is voteable (acts_as_voteable with Thumbs Up gem)
Could anyone give suggestions on how other wise model this questions and answers? For some reason this doesn't feel correct.
Essentially mutltiple groups will have the same question and answers except different poll results. I want to try and avoid creating a poll and questions for each group as this would result in over 100,000 records in the database.
Cheers
"Essentially mutltiple groups will have the same question and answers except different poll results. I want to try and avoid creating a poll and questions for each group as this would result in over 100,000 records in the database."
As I understood it you have Questions with a fixed set of Possible Answers, and you store the result in Response?
I would go with a 1:n relationship between Question and Answer,
and probably n:m between Group and Question, this way you can "reuse" Questions in multiple Groups.
Related
I'm a beginner for rails application, I have troubled some issue which is display related post, I already show post separately according to id I have not any idea how to show related post.
Below my code for show post separately according to id:
def postDetails
#details= Post.find(params[:post_id])
end
Now how can I rich this solution?
This is not an answer, so I'll delete if required.
--
Your question is highly ambiguous, meaning that it's open to interpretation in many different ways. Whilst not a problem, when it comes to application functionality, you need to be as specific as possible.
Contrary to the new buzzwords of "full stack engineer", "devops" etc - the core of computing is to design functions & algorithms which "compute" data. Your case is exactly the scenario where a professional developer would outline a spec, and work towards implementing it.
To answer your question as broadly as you asked it, you have to define how you wish to "relate" your posts.
There are several options (all involve data sampling) --
define each post by "tags" or similar categorization
create an algorithm to parse the title, pull out keywords & search for them
have users specifically define which posts are "related"
As you can see, there is one constant with the above - you need a "benchmark" to associate data. Be it keywords, tags, associated posts - you have to be able to identify the data you want.
Thus, you'll have to define the pattern you wish to employ. I can talk through each option; it would be too much to write without knowing how you want to do it.
My goal is to ask a series of questions. Kind of like flashcards. I have the questions in a table, and I can load them into a hash and ask them at random. The problem is that I want to be able to ask a particular question once per review session. The problem I have is that as soon as the page loads I lose the history and the hash resets to all the questions. How do you solve this using (just) Rails? I know the answer is probably "use JavaScript" but was wondering if it was possible using pure Rails.
One solution I thought of was creating a temp table and pulling all the questions there, and then deleting the question as soon as it's asked. Is that the best solution?
Just use rails session to store information about your survey between requests: http://www.justinweiss.com/articles/how-rails-sessions-work/.
I've just implemented a simple model in my app, to create a survey. Simple question and some answer.
There is no need to be connected to answer the survey, but I want people to answer it just one time. How can I do that?
I don't know how to track this easily: IP, user agent etc. But these things can be easily changed. Any idea?
Let's say you want to create a Digg.com-like site. Should the votes be its own separate model, or should the votes be a field in the table for the model of the object that is voted on?
It depends on how much information you want to store. If you just have a reference to something and a total score, then you don't need a model. If you have want to store who voted, how many up/down votes were received, timestamp when votes were received, and be able to rollback votes from unruly sources, then you'll need to keep each of those votes as their own model. Personally, I'd make each vote its own record, if I were designing such a system.
Considering Digg.com-like site requirement, I would say - own model. Greatly due to the need of so called "voting rings" detection - detecting groups of fake voters.
Other than that - I would go with fields. MySQL for example can update rows atomically (so they say, never tried it myself), what is supposed to be quite efficient. More information on the MySQL docs.
It depends if you want to keep related vote information or not. This has nothing to do with RoR but with database normalization.
If you want to keep extra information with the votes, like maybe the date it was recorded you should keep it in another table (and as such it will be another model). If not you can store it in the other objects table.
Trying to implement a rating system of users and postings.
What is the best schema for managing the multiple reputations.
A user has a reputation derived from postings and feedback(similar to SO).
Postings have a reputation too (again similar to SO).
My initial idea as to have one reputation table. The rows would correspond to the id of the user/posting and the value of the vote.
Two Questions:
Is this the best way of managing this?
The unique Ids of the user and posting records are auto incremented, the default value that rake would create. Seems like there is a possibility the unique_ids could collide. Is that valid concern? How could I mitigate this?
Thanks
I would have separate tables for the post reputation and user reputations. These are semantically different things and should be separated as such.
This way you can have one table which has a foreign key to the post, and the other with a foreign key to the user for which the reputation is applicable.