How to persist branching logic into database? - branch

We are building a survey engine for our internal use. I would like to know how to persist the question branching logic into the database? Any body done this before or any ideas on the schema for the database?
If the user responses with an answer, we need to skip to the next questions based on the logic added to the questions Each question can have multiple logic added to it.
For eg:
Question: Is it Sunny, Raining or Cloudy?
Answer: Raining.
The next question should be based on the previous answer.
if(Raining)
{
}
if(Sunny)
{
}
if(Cloudy)
{
}
how do I persist the above to the database and go from there?
Any bright ideas ?

You're essentially looking to persist a decision tree into a database. You'd want to store each question as a node and, in the interests of a normalized database, store the edges in a separate table relating questions that depend on other questions (directed edges), and walk as appropriate.
Edit: A simple design can be two tables: Questions and Edges. Questions just has id and question text. Edges can be answered_question_id, next_question_id, and answer. The first table is self-explanatory. The second table lists that if a question answered_question_id is asked and answered with something that either equals to or matches answer, forward to question next_question_id next.

Related

Designing a survey builder with a good data structure?

for my current project, I'm building a survey builder from scratch (some of the requirements are very unique). I'm having quite a hard time with the data model since it seems overly normalized to me. I'd love some input on it (since I'm not the most experienced programmer).
The situation:
Most of the question types stand by themselves and don't have any relation to surrounding questions (e. g. "How do you like the weather?" - "Fine"). Other questions need a module that relates them with their surrounding questions (e. g. Likert scale questions -- How satisfied are you with: a.) your school? your workplace?).
Currently, my solution is to put every question in a module. This results in a lot of modules with just one question in them.
Here is a sketch explaining the problem:
The normalized data structure looks like this (I'm using SQL):
looks ok. you will also need a place for the actual responders, and another for the actual responses those responders give to the questions.

Postgres - DB Design & Spring-Data-JPA query related suggestion required

Hello Friends,
I have a kind of requirement like, Student & Question are entities.
Both Entity are in many-to-many relation.
I would like to represent my idea is something likewise(refer below screen-shot. please correct me if any improvement is possible).
I would like to know from you guys is that,
1) is the above mentioned DB-design is good ? is there any improvement
then let me know.
And second one is related to query(JPQL),
2) it's most important, in spring-data-jpa, how would I implement in
such a way so that, even though user has not answered question then
also, those question needs to reflect under user-profile page that
this question is still not answered. Refer below screen-shot about
an expectation of this(second one) question.
Any help would be really appreciable!!

I want to create a quiz module. Which kind of database I should use SQL(Postgres) Or NoSQL(MongoDB)

I want to create a quiz module.
It will have tables like quiz details, quiz question and quiz answer.
Which kind of database I should use SQL(Postgres) Or NoSQL(MongoDB).
If NoSQL joins will be the problem then I have to store question and answers in one collection.
To keep question and answers (options) in the same collection is good approach?
For Quiz module, You will not get concurrent update\delete request for the same row. so i suggest to use NoSQL.
For NoSQL, you can use Question module as a separate collection and answer Collection with reference of Question's object_id. so structure will be normalized in good way.

How does refrence work $ref , x-template? attaching a common component to child components

Basically i am working on a project on which users can post questions and users can also answer to those questions. A post generally has upvote, downvote and comments for example … how do i design it, So let’s say there is comment button with every answers so what i want is when i click on comment button of any answer i should be able to get all the comments of that particular answer(this is backend i am not worrying about this).just like facebook or quora’s comment system, I am just think about front end part how to i do show when user click on comment button , will $ref work in this case or i have to think of other method , approach
And also let just say i have separate table for upvote downvote(one table for both) and similary answers and questions and users table … my concern is upvotedownvote table is going to grow faster than anything (6000 upvotes means 6000 rows, i am normalizing) . In this case join four table will be costly and will make it slower what i am thinking is to join three tables except upvotes table i.e fetching answers, users name who has answered and question also from fisrt three table and then passing all ids of currently loaded answers to database to get upvote downvotes count of each answers using some lifecycle hook method what would be the best way to do that , Any help would be appriciated thank you
Don't worry about the database size yet. 6000 rows may sound like a lot, but in reality it is a really small amount for a database. Most likely you won't encounter any performance problems at this scale and performance problems are best solved when you encounter them.
Your other question is a bit unclear what you are asking. Likely you will have something like a component that includes all the posts on the page and then a separate post component. When the user wants to view all comments you'll just send an Ajax request to the server, get an array of the comments and pass them to the post component inside v-for.

What mysql database tables and relationships would support a Q&A survey with conditional questions? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I'm working on a fairly simple survey system right now. The database schema is going to be simple: a Survey table, in a one-to-many relation with Question table, which is in a one-to-many relation with the Answer table and with the PossibleAnswers table.
Recently the customer realised she wants the ability to show certain questions only to people who gave one particular answer to some previous question (eg. Do you buy cigarettes? would be followed by What's your favourite cigarette brand?, there's no point of asking the second question to a non-smoker).
Now I started to wonder what would be the best way to implement this conditional questions in terms of my database schema? If question A has 2 possible answers: A and B, and question B should only appear to a user if the answer was A?
Edit: What I'm looking for is a way to store those information about requirements in a database. The handling of the data will be probably done on application side, as my SQL skills suck ;)
Survey Database Design
Last Update: 5/3/2015
Diagram and SQL files now available at https://github.com/durrantm/survey
If you use this (top) answer or any element, please add feedback on improvements !!!
This is a real classic, done by thousands. They always seems 'fairly simple' to start with but to be good it's actually pretty complex. To do this in Rails I would use the model shown in the attached diagram. I'm sure it seems way over complicated for some, but once you've built a few of these, over the years, you realize that most of the design decisions are very classic patterns, best addressed by a dynamic flexible data structure at the outset.
More details below:
Table details for key tables
answers
The answers table is critical as it captures the actual responses by users.
You'll notice that answers links to question_options, not questions. This is intentional.
input_types
input_types are the types of questions. Each question can only be of 1 type, e.g. all radio dials, all text field(s), etc. Use additional questions for when there are (say) 5 radio-dials and 1 check box for an "include?" option or some such combination. Label the two questions in the users view as one but internally have two questions, one for the radio-dials, one for the check box. The checkbox will have a group of 1 in this case.
option_groups
option_groups and option_choices let you build 'common' groups.
One example, in a real estate application there might be the question 'How old is the property?'.
The answers might be desired in the ranges:
1-5
6-10
10-25
25-100
100+
Then, for example, if there is a question about the adjoining property age, then the survey will want to 'reuse' the above ranges, so that same option_group and options get used.
units_of_measure
units_of_measure is as it sounds. Whether it's inches, cups, pixels, bricks or whatever, you can define it once here.
FYI: Although generic in nature, one can create an application on top of this, and this schema is well-suited to the Ruby On Rails framework with conventions such as "id" for the primary key for each table. Also the relationships are all simple one_to_many's with no many_to_many or has_many throughs needed. I would probably add has_many :throughs and/or :delegates though to get things like survey_name from an individual answer easily without.multiple.chaining.
You could also think about complex rules, and have a string based condition field in your Questions table, accepting/parsing any of these:
A(1)=3
( (A(1)=3) and (A(2)=4) )
A(3)>2
(A(3)=1) and (A(17)!=2) and C(1)
Where A(x)=y means "Answer of question x is y" and C(x) means the condition of question x (default is true)...
The questions have an order field, and you would go through them one-by one, skipping questions where the condition is FALSE.
This should allow surveys of any complexity you want, your GUI could automatically create these in "Simple mode" and allow for and "Advanced mode" where a user can enter the equations directly.
one way is to add a table 'question requirements' with fields:
question_id (link to the "which brand?" question)
required_question_id (link to the "do you smoke?" question)
required_answer_id (link to the "yes" answer)
In the application you check this table before you pose a certain question.
With a seperate table, it's easy adding required answers (adding another row for the "sometimes" answer etc...)
Personally, in this case, I would use the structure you described and use the database as a dumb storage mechanism. I'm fan of putting these complex and dependend constraints into the application layer.
I think the only way to enforce these constraints without building new tables for every question with foreign keys to others, is to use the T-SQL stuff or other vendor specific mechanisms to build database triggers to enforce these constraints.
At an application level you got so much more possibilities and it is easier to port, so I would prefer that option.
I hope this will help you in finding a strategy for your app.