I'm implementing a quizz and want to fetch questions from a Firestore.
How can I query questions one by one from the DB in a different order between players but being sure that I never show twice the same question to the same player.
Is it possible to give an array of IDs that I already fetched ? Or is there another solution that can help me ?
There is nothing built in to Firebase for that. The first approach that comes to mind would be to track what questions you've already asked, and find a next question at random with the approach described here. Then if you've already used that question, find another random one.
Related
I know this question is fairly simple for you and there are many related answers but none of them explain all what I need.
So you all must have been to YouTube, there you must have seen the Trending Posts Section, where all the videos which have the most views/likes/dislikes (I don't know exactly) w.r.t the time are listed. Now, all those videos are from different different channels.
I want to know:
There must be an algorithm or function inside the server to do that? If there is one, then when do it runs, i.e, are the results kept ready inside the server the same a google search engine --- which keeps the pages stored according to their ranking and whenever someone searches it delivers the result.
The above algorithm goes through every posts, right? But when? How does it knows that this post from this youtuber is getting this amount of views or a lot of views.
Now, after it knows which posts are trending --- where are they stored. Like, if we take mongodb database. Is it kept in a different collection like trending posts or their id's
I know the above questions must be confusing because of my half(or no) knowledge. But, please help me know it all. I am trying to get this answer for a very long time. Any guides or tutorials appreciated. Thanks!
For a "trending posts" feature you would have to store each view/like/etc (whatever you consider as a metric for "popular"). You also need to store a timestamp, so that you can select for "current popularity" as opposed to "in the past". And maybe store some identity of the viewer, so that each visitor is only counted once.
Next you have to find out which post is trending at the moment. For this you would need to find out the posts with the highest number of views in the past timespan. It is up to you (and the nature of the system you are running) whether you use hours, days, weeks or even months.
This query is probably too expensive to run on each pageview, plus the results don't change that much from minute to minute. So you would run this on some schedule, for instance once every hour. Again, it is up to you decide how accurate you want/need it. Maybe run this several times an hour, or just once a day. You do need to store the list of "trending posts" somewhere, so you can display it easily.
I am working on a new project where I have 500k questions to be stored in database. Each time a student answers a question, that ques is marked under visited category for that specific user. Thus, what a student should see on main page is question that he has never visited. So, my problem is that if 10 questions are posted on the main page, then each question will have to be first matched with collection of the visited question, check whether they are in the list of visited question for that user and then get posted on the main page. How should I minimize the time required for such kind of requirement? or Is my algorithm inefficient?
I'm trying to come up with a clean database design for a new project I'm working on. One of the data items I need to store in the database will come from an HTML form:
Q1: "Anticoagulated patient?" [YES, NO]
JavaScript;
(If yes is selected, an additional question is displayed):
Q2: "Type of Anticoagulant" [Warfari, Coumarin, Clopidogrel]
My question is, is it necessary to store the first question's response in the database? To me the data seems redundant. If the type is specified, then it can be assumed that the patient is "anticoagulated".
Once the form is submitted, the form will be accessed at a later point so the data can be ammended and the interface will need to reflect the state of the database. I should still be able to do this without needing to record the first question:
JavaScript;(If Q2 has a value, then the default option should be set to Yes
otherwise it should be set to No)
Q1: "Anticoagulated patient?" [Yes, No]
JavaScript;(Only display if Q1 is set to Yes):
Q2: "Type of Anticoagulant" [Warfari, Coumarin, Clopidogrel]
What are your thoughts on this?
I would say the extra space required to store the response to question 1 will be far outweighed by the amount of extra logic involved in marking Q2 as implying Q1. Keep it simple!
I think the two questions should indeed be handled on the client-side, as you suggested. This will provide a better user experience.
As for the database, don't use two fields, one is more than enough. Note that even if you don't show the second question dynamically, you can still store the answer somewhere else (such as the web server session) and not the back-end database.
I think , you have make right decision on this, but just think about the future and extending the application logic , maybe you need to add another question later then you will have to store the question in db,
Briefly for current situation it is adequate to store the answer.
I am developing an application - which would have users answer maybe 10 questions - which would have 3-4 options for each question. At the end of the 10th question, based on the responses, it would need to suggest a certain solution. Since there are 100's of permutation and combinations - what's the logic that would be required to use and the database design,
thanks
EDIT some more detailed explanation
if my application is used to recommend a data plan from various mobile operators - based on the user answering questions like the time spent on the internet, the type of files being downloaded and so on. So, if the response to question 1 was a and question 2 was c, etc - then it would be a certain plan. If the response to question 1 was b and for question 2 it was c, then it would recommend a certain plan. So, if there were 10 questions - then the combinations can be quite large. So is there a certain algorithm that can handle this?
I. what would be the logic?
If I understand correctly, you would define "rules" such as
If the answer to question 5. is either A or B then the suggested plan would be planB, otherwise execute the rest of the rules.
So you would use a rule engine e.g.: http://www.jboss.org/drools/
II. what would be the database design?
This is quite simple:
USERS table,
QUESTIONS table and
ANSWERS table which would refer to the two others
Possibly there would be a QUESTIONNAIRE table as well, and the QUESTIONS table would refer to it.
Just a 'quick' comment, consider letting the user see changes in what company they could be recommended as they answer every question.
For example, if I am most interested in price that would be the question I would answer first and immediately see the 3 cheapest plans/products recommended to me.
The second question could be coverage and if I then could see the 3 plans with best coverage (in my area) that would be interesting too.
When I answer the third question about smart phone features and I say I want internet, then the first question should spit out the 3 cheapest plans/products that include internet, obviously they could change.
And so on...
Maybe it also could be a good idea to let the user "dive into" each question and see the full range of options for that answer. As a user I would appreciate that.
Above comments is just how I would appreciate if a form was made for me, I don't want to answer 10 questions about stuff I'm not really putting any value on, each user is different and will prefer to make their choice on their questions.
So, based on above it would be like a check list where the top answers would be the plans/products with the most fitting check marks. And to give immediate responses (as the user answer/alter each question), here AJAX would probably be your choice.
how does stackoverflow manage permalinks. For example an arbitary qn like: ASP.NET + jQuery + Dynamically Created HyperLink controls In this case what happens if the same user posts another qn with the same title. I think the number before- /1002230/ is the key but on what basis is that created. Is it an indicator of how many questions there are in stackoverflow.
This doubt is relevant to me because i am trying to use the title of a blogpost in the permanent link for it. However this won't allow for multiple blogpost with the same title. Neither do i want to use id number. I am infact using appengine for this app so the generated key is something like 'ahVzYW5qaGFjaG9vbGhhLXNhbmRib3hyCwsSBUFjdG9uGFUM' which is surely not nice. So any hints on how to prettify my url
Thanks
Rather than using the Key().str(), it might be nicer to use the Key's id or key_name with Model.get_by_id() or Model.get_by_key_name(). These are both more user friendly (integer or supplied string respectively).
The number is the question id which is unique - they only increment and are not reused. The human-readable string is ignored by the server when you retrieve the page by URL - it's for convenience and pretty look - to solve the same task you have. So each question URL has two parts - the machine-readable (the starting part and the question id) and the human-readable - the filtered question title afterwards.
With the exclusion of deleted questions the number is the total number of questions on the site. Numbers of the deleted questions are not reused, so no conflict is possible.
The ID number does give some indication of how many total posts there are. I believe I recall from a podcast that both questions and answers are stored as 'posts', but comments may be posts as well.
The approach I like best is to use URLs formatted as "/1234/slug-goes-here" (like StackOverflow) or "/1234-slug-goes-here". With a little cleverness, you can ignore the content of the slug, and fetch based on the ID only, which means that links work even if they were truncated by mail software, IRC, etc.
The other approach, App Engine wise, is to use key names - make the slug the key name, which means you can look it up with MyModel.get_by_key_name(slug). This is how Bloog does it.