sql >> Databasteknik >  >> RDS >> Mysql

Lagring av dynamisk formulärdata i DBMS, letar efter det optimala tillvägagångssättet

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 flera questions . 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.




  1. Hur Cotd() fungerar i PostgreSQL

  2. Hur AUTOINKREMERAR man från ett visst antal/offset?

  3. Prestationer / märkessystem

  4. Direkt åtkomst till serverdatabasen via Ajax (utan PHP eller någon annan mellanliggande)