Du har ställts inför ett vanligt problem:Att försöka använda något statiskt (databas med fördefinierad struktur) för något dynamiskt (en massa individuella datamängder som bara har en sak gemensamt:de kommer från formulär). Vad du vill är görbart med databaser men skulle vara betydligt lättare att klara sig utan, men eftersom jag antar att du verkligen vill använda en databas för detta, så här skulle jag göra:
- Du har ett
document
(eller frågeformulär ) som innehåller fleraquestions
. Dessa båda är generiska nog och kräver sina egna tabeller, precis som du har gjort hittills. - Varje fråga har en
type
som definierar vilken typ av fråga det är (multiple select, freeform, select one... ) och naturligtvis har frågan ocksåoptions
. Så det är två bord till. Resonemanget här är att frikoppling av dessa från den faktiska frågan tillåter att en viss abstraktionsnivå existerar och dina frågor kommer fortfarande att vara något enkla även om de kanske är så långa.
Så, varje dokument har 1..n till frågor, varje fråga har 1 typ och 1..n alternativ. Hoppa över lite, här är vad jag tänker på med länktabeller etc.
Document
bigint id
DocumentQuestions
bigint document_id
bigint question_id
Question
bigint id
varchar question
QuestionType
bigint question_id
bigint type_id
Type [pre-filled table with id:type pairs, such as 1=freeform, 2=select one etc.]
QuestionOptions
bigint id
bigint question_id
varchar description
varchar value
Answers
bigint id
bigint document_id
[etc. such as user_id]
QuestionAnswers
bigint answer_id
bigint question_id
bigint questionoptions_id
Denna typ av design tillåter flera saker:
- Frågorna i sig är återanvändbara, mycket praktiska om du gör en generisk "svara på dessa x slumpmässiga frågor från en pool av y frågor ".
- Nya typer kan enkelt läggas till utan att bryta befintliga.
- Du kan alltid navigera genom strukturen ganska enkelt, till exempel "Vad hette dokumentet för detta enstaka frågesvar jag har? " eller "hur många personer har svarat felaktigt på den här frågan?"
- Eftersom typerna är separerade kan du skapa ett (webb)gränssnitt som enkelt återspeglar tillståndet i databasen - ännu bättre, om typen ändras behöver du kanske inte ens röra din användargränssnittskod alls. >
- Eftersom varje eventuellt alternativ för en fråga är en egen rad i
QuestionOptions
tabell kan du få det faktiska värdet mycket enkelt.
Det uppenbara problemet med detta är att det kräver ganska strikt koppling mellan borden för integritet och det kommer att vara jobbigt att få igång ordentligt vid start. Också eftersom value
i QuestionOptions
är varchar måste du kunna analysera saker mycket och du kanske till och med vill introducera ett annat fält för konverteringstips.
Hoppas detta hjälper även om du inte alls skulle hålla med om min lösning.