I need to solve a problem within job booking software and am hoping to find a good way of doing that.
The current system uses a set of check boxes to represent the problem description when a customer rings up. These check boxes are useful to admin, but not really from a customer perspective.
My thoughts were to have 1 or more english representations of these checkbox items, corresponding to each one. That would be easily searchable on the fly while a customer was on the phone explaining their problem.
Sometimes the telephone operator may need to ask a further question though, and I will need to allow for a level of questioning after the initial problem description.
At the end of the problem diagnosis, this should still represent 1 or more checkboxes at the back end.
An example:
A customer rings up complaining that "my water is cold".
Telephone operator types in "cold" and multiple results are returned "repair hot water system - gas" & "repair hot water system - electric"
In order to correctly choose, another set of questions is presented for the telephone operator to ask. "Is your HWS Gas?", "Is your HWS Electric?"
Once that is selected, the correct item is associated with the job.
I need to find the best way to represent this?
I guess the core elements are:
The low level checkbox descriptions
The english descriptions (1 or more per checkbox)
The secondary questions to narrow down the description
Any help would be appreciated!
Basically, one question can have multiple answers. Each answer can lead to multiple questions. This can go on for multiple levels. Here is a very basic description of how I would approach tackling this...
Here is a suggested lookup table structure:
table: Questions (QId, QuestionText) all questions are saved here
table: Answers (AId, AnswerValue) all possible answers are here (yes, no, cold, hot, warm, not working, etc)
table: QuestionAnswers (QAId, QId, AId) question answer combinations are stored here (is the ac working? yes / no)
table: RelatedQuestions (QAId, QId) for a given question answer combination, what is the next set of question(s) to ask ("is the ac working - no" then ask "do you have power?, do you have an AC in the house", "is this the car a/c or the home AC?")
Here is a suggested data table structure:
table: CustomerInfo (CuId, CDetails...) one record per customer
table: ContactInfo (CId, Cdetails...) one record each time a customer is contacted
table: QASeriesForContact (QACId, CId, SearchTerm) the search term / issue (you can have multiple of these per call, right?)
table: QASeriesDetails (QASDId, QACId, QAId) for each problem, track the question answers until resolution
I know we are going to have to modify this a fair bit to suit your needs - fire away and I will do my best to help.
Related
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
I'm about to develop a database used for storing questionnaire with a indefinite number of questions. This database will communicate with a server, used for registering the answers and retrieving them when needed. For each user, I need to store the answer to each question, which is server-side mandatory.
The structure should be like that:
QUESTIONNAIRE:
Questionnaire n.1 (Question1,Question2,...,QuestionN)
Questionnaire n.2 (Question1,...,QuestionM)
...
USER:
User1
User2
...
ANSWERS
User1 - Questionnaire n.1 (AnswToQuestion1, AnswToQuestion2...AnswToQuestionN)
User2 - Questionnaire n.1 (AnswToQuestion1, AnswToQuestion2...AnswToQuestionN)
User2 - Questionnaire n.2 (AnswToQuestion1, AnswToQuestion2...AnswToQuestionM)
Given the specifications above, I face 2 major problems:
Indefinite number of questions means that a table must store each individual questions for each questionnaire
There should be a corrispondence between question and answer
I thought about 2 different solution for facing such problems, but I can really decide between the 2.
The first one would consist in creating 5 differents table, as follows:
The idea is basically to store users in USER table, and for each user store an ANSWER which refers to a specific questionnaire. This gives an information like 'user x has replied to questionnaire'. Then, the unique id id:ANSWER would be used to mark a given answer in MARKETINGANSWER. The QUESTIONNAIRE table would save each instance of a questionnaire, and provide an unique id to link each different question in the MARKETINGQUESTION table. At the end, the unique id id:MARKETINGQUESTION would be used to map a question to a given answer.
What does not convince me: this has too many layers of indirection. I do not like the forced connection of MARKETINGANSWER and MARKETINGQUESTION, yet I need a way to map them. Moreover, I need the general table for ANSWER, since it provides some general info about the questionnaire (the hidden columns).
Then I thougth about a second approach: creating an unique ANSWER and QUESTIONNAIRE table which would envelop in a TEXT attribute the series of answers/questions separated by a special escape character (such as #&, for instance). This would ruin the mapping, but it can be implemented in the web application - I was thinking about a control on the number of question/answer, the ordering would be ensured on questionnaire registration and commit on the database. Moreover, the schema would be cleaner. Yet, I would lose a consistent representation in the database schema.
I would like, if possible, some suggestion about the proposed solutions. I am pretty sure there is something simple I cannot quite grasp.
Thank you in advance.
I am building a sample online examination platform (I'm in the process of learning Ruby on Rails) with the following specifications:
There are 1000 different multiple choice questions.
Each question can have up to 5 possible answers, 1 of them is correct.
A user is presented with 10 random questions at a time (let's call this a test). If a user answers a question correctly 2 times, then this question will not be shown to him again.
A user passes the exam if he has answered every question correctly 2 times, in other words when there are no more questions left to show to him.
A first try :
student
-student_id
-name
question
-question_id
-text
option
-option_id
-text
-is_correct
-question_id
student_answer
-student_id
-question_id
-option_id
Although we could only store the correct questions, I've decided to include the 'option_id' in the student_answer table in case I need to display statistics (hardest question etc) in the future.
So up to this point, a question has many options, every option belongs to a single question and every time a student answers a question a student_answer row is created.
It seems to me that this approach would have some performance issues since for each test we'd have to select all the answers given by the user, group them by the question_id, for each question calculate the correct times it has been answered, get a set of question_id that shouldn't be displayed and finally select 10 random questions out of the 1000 initial ones minus those we just excluded.
Another thought I had was to have a JSON array in the form of {[0,0,1,...,1]} for every user. Each cell would be the number of correct answers for the question with an id matching the array index but I find that a bad idea.
Since I'm relatively a beginner when it comes to database design I'd like some feedback on my approach. Please feel free to suggest ways that are completely different than the above.
Thank you very much.
I think you may need to include the question_id in the option table.
One approach would be to move some of the processing into Ruby.
Select the 1000 questions.
Select the answers given by the user: SELECT count(*) counter, question_id, option_id FROM student_answer JOIN option USING (question_id,option_id) WHERE student_id=x AND option.is_correct=1 GROUP BY question_id,option_id HAVING counter>1
Randomize the 1000 questions in ruby, iterate though them, and exclude any that were found in your query of correct answers for this student. Stop after 10 questions.
If only one answer can be correct, then why store the correctness in the option table, the question record should contain the foreign key of the correct answer.
You describe some entities not addresed by your design. You maybe don't need to store 'a test' but this, and a primary key on student_answer makes for a model which makes it a bit easier to answer different questions about the data.
I think you have a good approach going, I would probably do the same. - symcbean does make a good point above, but my solution for this would be to store a boolean column within the student_answer table for whether the answer is correct.
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.
this is a follow-up question on my previous one.We junior year students are doing website development for the univeristy as volunteering work.We are using PHP+MySQL technique.
Now I am mainly responsible for the database development using MySQL,but I am a MySQL designer.I am now asking for some hints on writing my first table,to get my hands on it,then I could work well with other tables.
The quesiton is like this,the first thing our website is going to do is to present a Survey to the user to collect their preference on when they want to use the bus service.
and this is where I am going to start my database development.
The User Requirement Document specifies that for the survey,there should be
Customer side:
Survery will be available to customers,with a set of predefined questions and answers and should be easy to fill out
Business side:
Survery info. will be stored,outputed and displayable for analysis.
It doesnt sound too much work,and I dont need to care about any PHP thing,but I am just confused on :should I just creat a single table called " Survery",or two tables "Survey_business" and "Survey_Customer",and how can the database store the info.?
I would be grateful if you guys could give me some help so I can work along,because the first step is always the hardest and most important.
Thanks.
I would use multiple tables. One for the surveys themselves, and another for the questions. Maybe one more for the answer options, if you want to go with multiple-choice questions. Another table for the answers with a record per question per answerer. The complexity escalates as you consider multiple types of answers (choice, fill-in-the-blank single-line, free-form multiline, etc.) and display options (radio button, dropdown list, textbox, yada yada), but for a simple multiple-choice example with a single rendering type, this would work, I think.
Something like:
-- Survey info such as title, publish dates, etc.
create table Surveys
(
survey_id number,
survey_title varchar2(200)
)
-- one record per question, associated with the parent survey
create table Questions
(
question_id number,
survey_id number,
question varchar2(200)
)
-- one record per multiple-choice option in a question
create table Choices
(
choice_id number,
question_id number,
choice varchar2(200)
)
-- one record per question per answerer to keep track of who
-- answered each question
create table Answers
(
answer_id number,
answerer_id number,
choice_id number
)
Then use application code to:
Insert new surveys and questions.
Populate answers as people take the surveys.
Report on the results after the survey is in progress.
You, as the database developer, could work with the web app developer to design the queries that would both populate and retrieve the appropriate data for each task.
only 1 table, you'll change only the way you use the table for each ocasion
customers side insert data into the table
business side read the data and results from the same table
Survey.Customer sounds like a storage function, while Survey.Business sounds like a retrieval function.
The only tables you need are for storage. The retrieval operations will take place using queries and reports of the existing storage tables, so you don't need additional tables for those.
Use a single table only. If you were to use two tables, then anytime you make a change you would in effect have to do everything twice. That's a big pain for maintenance for you and anyone else who comes in to do it in the future.
most of the advice/answers so far are applicable but make certain (unstated!) assumptions about your domain
try to make a logical model of the entities and attributes that are required to capture the requirements, examine the relationships, consider how the data will be used on both sides of the process, and then design the tables. Talk to the users, talk to the people that will be running the reports, talk to whoever is designing the user interface (screens and reports) to get the complete picture.
pay close attention the the reporting requirements, as they often imply additional attributes and entities not extant in the data-entry schema
i think 2 tables needed:
a survey table for storing questions and choices for answer. each survey will be stored in one row with a unique survey id
other table is for storing answers. i think its better to store each customers answer in one row with a survey id and a customer id if necessary.
then you can compute results and store them in a surveyResults view.
Is the data you're presenting as the questions and answers going to be dynamic? Is this a long-term project that's going to have questions swapped in and out? If so, you'll probably want to have the questions and answers in your database as well.
The way I'd do it would be to define your entities and figure out how to design your tables so relationships are straightforward. Sounds to me like you have three entities:
Question
Answer
Completed Survey
Just a sample elaboration of what Steven and Chris has mentioned above.
There are gonna be multiple tables, if there are gonna be multiple surveys, and each survey has a different set of questions, and if same user can take multiple surveys.
Customer Table with CustID as the primary key
Questions Table with a Question ID as the primary key. If a question cannot belong to more than one survey (a N:1 relationship), then can also have Survey ID (of table Survey table mentioned in point 3) as one of the values in the table.
But if a Survey to Question relationship is N:M, then
(SurveryID, QuestionID) would become a composite key for the SurveyTable, else it would just have the SurveyID with the high level details of the survey like description.
UserSurvey table which would contain (USerID, SurveryID, QuestionID, AnswerGiven)
[Note: if same user can take the same survey again and again, either the old survey has to be updated or the repeat attempts have to stored as another rows with some serial number)