Przechowywanie danych formularzy dynamicznych w DBMS, szukanie optymalnego podejścia

Zetknąłeś się z powszechnym problemem:próba użycia czegoś statycznego (baza danych o predefiniowanej strukturze) do czegoś dynamicznego (kilka pojedynczych zestawów danych, które mają tylko jedną wspólną cechę:pochodzą z formularzy). To, czego chcesz, jest wykonalne z bazami danych, ale byłoby to znacznie łatwiejsze do zrobienia bez, jednak ponieważ zakładam, że naprawdę chcesz użyć do tego bazy danych, oto co bym zrobił:

• Masz document (lub kwestionariusz ), który zawiera wiele questions . Oba są wystarczająco ogólne i wymagają własnych tabel, tak jak robiłeś to do tej pory.
• Każde pytanie ma type który określa rodzaj pytania (wybór wielokrotny, dowolny, wybór jednego... ) i oczywiście pytanie ma również options . Więc to dwa stoliki więcej. Rozumowanie tutaj jest takie, że oddzielenie ich od rzeczywistego pytania pozwala na istnienie pewnego poziomu abstrakcji, a Twoje zapytania nadal będą dość proste, chociaż prawdopodobnie dłuuugie.

Tak więc każdy dokument ma 1..n do pytań, każde pytanie ma 1 typ i 1..n opcje. Pomijam trochę, oto co myślę o tabelach linków itp.

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

Ten rodzaj projektu pozwala na kilka rzeczy:

• Samych pytań można używać wielokrotnie, co jest bardzo przydatne, jeśli tworzysz ogólne „odpowiedz na te x losowe pytania z puli y pytań ".
• Nowe typy można łatwo dodawać bez naruszania istniejących.
• Zawsze możesz dość łatwo poruszać się po strukturze, na przykład „Jaka była nazwa dokumentu dla tej jednej odpowiedzi na pytanie, którą mam? " lub "ile osób odpowiedziało niepoprawnie na to jedno pytanie?"
• Ponieważ typy są rozdzielone, możesz stworzyć (internetowy) interfejs użytkownika, który w łatwy sposób odzwierciedla stan w bazie danych - jeszcze lepiej, jeśli typ się zmieni, możesz nawet nie musieć w ogóle dotykać kodu interfejsu użytkownika.
• Ponieważ każda możliwa opcja pytania jest osobnym wierszem w QuestionOptions tabeli, możesz bardzo łatwo uzyskać rzeczywistą wartość.

Oczywistym problemem jest to, że wymaga to dość ścisłego połączenia między stołami w celu zachowania spójności i będzie trudne do prawidłowego działania na początku. Również od value w QuestionOptions jest varchar, musisz być w stanie dużo analizować, a nawet możesz wprowadzić inne pole dla wskazówek dotyczących konwersji.

Mam nadzieję, że to pomoże, nawet jeśli w ogóle nie zgodzisz się z moim rozwiązaniem.