I'm investigating the possibility of writing a web-based question and answers engine to assist my girlfriend in her line of work.
What I mean by "question and answers" engine is, that the database (and ultimately user interface) can present many styles of question to an end user - not specifically multiple choice, the questions could be "fill in the blank(s)" or "sqrt(189) equals" or "change the words in the paragraph" or a "word-search" style question with many correct answers.
As a more specific example, if a question was "fill in the missing words: 'the ____ brown ____ jumps over the ____ dog'" and the user is presented with various answers. Likewise, another specific answer could be "list as many words you can make from the word: 'antidisestablishmentarianism'".
Having done some searches already on stackoverflow, there have been some similar questions raised however none seemed to fit the mould of what I'm wanting.
As I see it, I can have a single questions table...
TABLE Questions
QuestionID UNIQUE INT
Question NTEXT // The question text (could include markup for web)
Options NTEXT // Could be a CSV list of possible options (for multi-choice type questions)
QuestionTypeID INT // ID of the question type record (more for the user-interface)
TABLE QuestionTypes
QuestionTypeID UNIQUE INT
Description NVARCHAR(100)
TABLE Answers
AnswerID UNIQUE INT
UserID INT // Related User record
QuestionID INT // Related Question record
Answers NTEXT // Could this be a CSV list of answers??
I can see how the above would work for very simple, single or multiple choice answers but I'm not sure how it would work for different styles of question.
Another thought I had was having different tables handling different QuestionTypeID values, for example:
TABLE QuestionType1 // Table styled to question type 1
QuestionType1ID UNIQUE INT
QuestionID INT // Related question record
...
TABLE QuestionType2 // Table styled to question type 2
QuestionType2ID UNIQUE INT
QuestionID INT // Related question record
...
But I can't really see how this would work. Am I thinking about this or approaching it in the wrong way?
I'd appreciate any help (if the question makes sense in the first place)!
Regards,
K
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
As a developer, a common mistake that I keep on repeating is assuming the data type of a column. I have read multiple articles regarding SQL column naming convention but have not seen any reference regarding data type as part of the column name - specifically for SQL Server.
E.g. Revenue_f for float, Organization_v for varchar, AccountNumber_i for integer and so on.
This must have been thought of already before but I want to know the reason why it is not being used, or an expert's input regarding the matter; pointing me to the right article/documentations will be greatly appreciated.
That is a horrible naming convention. Consider how awful it would be if you need to change AccountNumber to a character datatype. Do you then go back and rename the column and change every single query everywhere? Or do you leave the suffix in your column name even though it is no longer accurate? If you want to know the datatype of a column the ONLY way is to look at the definition of the table.
Also, a single character really is kind of useless. How do you handle nvarchar vs varchar? And what about the scale?
P.S. Even though I wrote an answer I am voting to close this question because it is primarily opinion based and as such is considered off topic for SO.
I'm working on a web app about online questionnaires forms and i'm having a problem regarding saving on database question's visibility.
In our forms the visibility of some questions is conditioned by the answers of other questions, for example you can see question "B" only if you answered question "A".
For this simple case i have no problem to insert this information in the database, the problem is when i have visibility's condition like this: D = (A AND B) OR C.
I found this post on stackoverflow with a similar problem but the final solution was not posted: storing and parsing boolean expressions in database
I can serialize the formula and save the string on the DB but i don't like this solution cause i lose all the DB bond, i thought to save for each condition the next condition and specify the logical connective but this solution is not good for the parenthesis; the only good idea for now is to save the single condition on a table and the condition's relation on an other table; any suggestion please?
I've been thinking about how I should design a database to hold exam questions for a little over a year now (on and off, mostly off).
First, a short description of what I'm after. I would like to design a database flexible enough to store different question types (for example, short response or multiple choice questions), and be able to select any number of those questions to be stored as an exam.
My question is:
How should the exam questions be stored?
Since different question types require different fields to store, if I was to put them all under the same table questions, there will be a lot of extra fields that are never used.
If I separate the question types into different tables, it'll be a lot harder to store the question_id in some exam_questions table, since they will come from different tables.
I also can't think of a flexible way to store the information.
For example,
questions
- id
- question
- type (multiple choice, short response)
- choice_1 ( used for multiple choice questions)
- choice_2
- choice_3
- choice_4
- choice_5
- answer (short response answer here, or just a/b/c/d/e for multiple choice, t/f for true or false)
Would a design like this be recommended? If not, does anyone have any advice?
I also have another question:
If I want to store student responses to one of these exams, would it be inefficient to store them like this?
exam_responses
- id
- student_id
- exam_id
- question_id or question_number
- response
- mark
Thank you in advance. If you would like any other information, or if there is anything wrong with this question, please leave me a comment and I'll try and have it fixed as soon as possible.
I would have separate question and answer tables and join them using a question2answer table
question
--------
- id
- question
- type (multiple choice, short response)
answer
------
- id
- GUIorder (so you can change the sort order on the front end)
- answer
question2answer
---------------
- questionid
- answerid
Now everything is dynamic in terms of building the question and you don't have empty columns.
A quick join brings you back all the parts to the main question
Your exam_responses table can now have the following
- id
- questionid
- answerid
- studentid
- response
- mark
I think storing five columns for each response in the questions table is not a good design. If the number of choices for the question becomes 6 you will have to add one more column. Also, if there are just two choices, the remaining columns will stay empty. So it better be in two separate tables:
questions
- id
- question
- type (multiple choice, short response)
- answer (short response answer here, or just a/b/c/d/e for multiple choice, t/f for true or false)
question_choices
- id
- question_id
- choice
Then you can get the list of choices for each particular question by joining them based on questions.id=question_chocies.question_id condition.
In case of exam responses, you should divide in two tables too in order not to repeat information about student_id, exam and mark for each question of the exam. So it should be something like:
student_exam
- id
- student_id
- exam_id
- mark
student_exam_responses
- exam_id
- question_id or question_number
- response
These two tables can be connected based on the student_exam.id=student_exam_responses.exam_id condition.
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 8 years ago.
Improve this question
Hi guys so I have a question about nick name searches.
I have a very large database and in my Accounts Entity I have a firstname column. When a user searches for an account by first name, it is possible that they may be using a nickname. For example searching for Bob, should also return Robert.
The way I would think to do this would be to create a table called nickname, with two columns, the nickname, and name. That way we map bob->robert.
Then when doing the query make the where clause look like this "WHERE firstname IN (SELECT name FROM nickname WHERE nickname = 'bob')"
The two problems I have is, the query above seems very inefficient, and would be very slow over large data sets (I could be wrong here so please tell me if so, when I say large data set I mean 14 million rows).
The Second problem I have is where to get the Nickname data from. This is the only thing I have found so far: https://code.google.com/p/nickname-and-diminutive-names-lookup/downloads/list
Any help would be greatly appreciated.
One option would be to use full text search instead:
http://www.postgresql.org/docs/current/static/textsearch.html
This would allow you to add custom dictionaries, among other colorful features:
http://www.postgresql.org/docs/current/static/textsearch-dictionaries.html
I had to solve a similar problem. We had a table with name variations that were linked to an individual. This was for a database of authors.
We then created a mapping table with soundex and double metaphone entries for these names (pre-generated) then did queries against that table to find individuals.
If you're not familiar with soundex or double metaphone, they are phonetic algorithms to match when using misspellings and similiar names. Soundex was developed for the US Census.
In our case, we already had the variations of every name the person published as rather than a generic list of names. However, the soundex algorithm can help with similar spellings. You'll still need to get a nickname list from somewhere, but this should help with the performance.
The reason I suggested two algorithms is that we had a lot of collisions using just one, but with both of those together it was a rather good filter. Double Metaphone worked better for non Western European names.
I'd suggest adding a front end element to let your customer service people (or customers) add their nickname too. Customers can help you build up a nickname list and you can use known nicknames to help with fuzzy searches on others eventually.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
What is the best way to create multi-language database? To create localized table for every table is making design and querying complex, in other case to add column for each language is simple but not dynamic, please help me to understand what is the best choose for enterprise applications
What we do, is to create two tables for each multilingual object.
E.g. the first table contains only language-neutral data (primary key, etc.) and the second table contains one record per language, containing the localized data plus the ISO code of the language.
In some cases we add a DefaultLanguage field, so that we can fall-back to that language if no localized data is available for a specified language.
Example:
Table "Product":
----------------
ID : int
<any other language-neutral fields>
Table "ProductTranslations"
---------------------------
ID : int (foreign key referencing the Product)
Language : varchar (e.g. "en-US", "de-CH")
IsDefault : bit
ProductDescription : nvarchar
<any other localized data>
With this approach, you can handle as many languages as needed (without having to add additional fields for each new language).
Update (2014-12-14): please have a look at this answer, for some additional information about the implementation used to load multilingual data into an application.
I recommend the answer posted by Martin.
But you seem to be concerned about your queries getting too complex:
To create localized table for every table is making design and querying complex...
So you might be thinking, that instead of writing simple queries like this:
SELECT price, name, description FROM Products WHERE price < 100
...you would need to start writing queries like that:
SELECT
p.price, pt.name, pt.description
FROM
Products p JOIN ProductTranslations pt
ON (p.id = pt.id AND pt.lang = "en")
WHERE
price < 100
Not a very pretty perspective.
But instead of doing it manually you should develop your own database access class, that pre-parses the SQL that contains your special localization markup and converts it to the actual SQL you will need to send to the database.
Using that system might look something like this:
db.setLocale("en");
db.query("SELECT p.price, _(p.name), _(p.description)
FROM _(Products p) WHERE price < 100");
And I'm sure you can do even better that that.
The key is to have your tables and fields named in uniform way.
I find this type of approach works for me:
Product ProductDetail Country
========= ================== =========
ProductId ProductDetailId CountryId
- etc - ProductId CountryName
CountryId Language
ProductName - etc -
ProductDescription
- etc -
The ProductDetail table holds all the translations (for product name, description etc..) in the languages you want to support. Depending on your app's requirements, you may wish to break the Country table down to use regional languages too.
I'm using next approach:
Product
ProductID OrderID,...
ProductInfo
ProductID Title Name LanguageID
Language
LanguageID Name Culture,....
Martin's solution is very similar to mine, however how would you handle a default descriptions when the desired translation isn't found ?
Would that require an IFNULL() and another SELECT statement for each field ?
The default translation would be stored in the same table, where a flag like "isDefault" indicates wether that description is the default description in case none has been found for the current language.