Projektowanie bazy danych kwestionariuszy - który sposób jest lepszy?

Mam JEDEN długą stronę HTML, kilka zestawów pytań podzielonych na małe sekcje (ok. 15 podsekcji na jednej stronie), w sumie pytania to około 100 pytań: różni się od wprowadzania, wielokrotnego wyboru, pól wyboru, przycisków opcji, pola tekstowego, i przesyłanie plików. Jedno pytanie może zawierać wiele odpowiedzi uzyskanych z grupy pól wyboru, grupy listy wyboru, grupy wielokrotnego wyboru lub wszystkich z nich w jednej odpowiedzi. Myślałem, że skorzystam z tego projektu bazy danych poniżej, ale ostatnio dowiedziałem się, że to jednak nie jest dobre podejście.

1. Jeden klient może mieć tylko jeden zestaw pytań: jeden klient na 100 pytań.
2. W przypadku starego podejścia nie trzymam pytania w bazie danych, ale zamiast tego przypisuję jako stałe kodowanie PHP. Problem polega na tym, że muszę porównać pytanie w PHP, aby zsynchronizować je z odpowiedzią w bazie danych. Gdyby jedno pytanie zostało zmienione / usunięte / przeniesione z PHP, na pewno zgubiłbym się, aby dopasować je do odpowiedzi w bazie danych Kwestionariusz. Lepsze rozwiązanie?
3. Czy mogę zachować wiele odpowiedzi uzyskanych z wielu elementów w formie w jednym polu jako jedną odpowiedź? Jak mogę pobrać to pole i wyświetlić je ponownie w celu wyświetlenia przez klienta w formularzu?
4. Którą opcję poniżej powinienem wybrać?

OPCJA 1: Stare podejście (1 stół)

TABELA: Kwestionariusz

• ID (PK)
• Identyfikator klienta
• Status
• A1
• A2
• A3
• .
• .
• .
• A100

OPCJA 2: Nowe podejście (2 tabele)

TABELA: Pytanie

• QID (PK)
• Pytanie (varchar)

TABELA: Odpowiedź

• POMOC (PK)
• Identyfikator klienta
• QID (int)
• Odpowiedź (varchar)

Lub OPCJA 3?

Zdecydowanie nie koduj kwestionariusza na stałe. Użyj relacyjnej bazy danych lub plików XML. Proponuję następujące tabele

• Questionnaire: Ogólny opis kwestionariusza. Tytuł, nazwa ankiety, data wydania kwestionariusza, wersja itd.

• Section: Sekcje, w których utworzono kwestionariusz. Numer sekcji, tytuł sekcji, opis.

• Question: Pytania należące do sekcji. Numer pytania, tekst pytania, opis, typ pytania (tekst, wybór wielokrotny itp.).

• Question_Choice: Możliwe odpowiedzi należące do pytania odpowiadającego pojedynczym polom wyboru, przyciskom opcji i tak dalej. Tekst wyboru, numer wyboru, zamówienie.

• Respondent: Osoby odpowiadające na pytania. Dane osobowe, numer użytkownika.

• Interview: Wywiady, testy lub ankiety (w zależności od charakteru kwestionariusza) należące do jednego respondenta i jednego kwestionariusza. Jeśli respondent zawsze może odpowiedzieć tylko na jeden kwestionariusz (lub jeśli ankieta jest anonimowa), ta tabela jest nieaktualna i można ją połączyć z tabelą Respondent. Data wywiadu (lub data testu lub data ankiety), osoba przeprowadzająca wywiad (jeśli dotyczy).

• Answer: Odpowiedzi należące do jednego wywiadu (lub respondenta, patrz wyżej) i jednego pytania. Odpowiedz na tekst (w przypadku pytań typu tekstowego), wybór (w przypadku przycisków opcji).

• Answer_Choice: Wybory należące do jednej odpowiedzi i jednego pytania_wyboru, gdy można zaznaczyć wiele opcji.

Jest to bardzo znormalizowane podejście; Można jednak zdecydować o połączeniu wyborów w jeden ciąg znaków lub zapisać je jako wzór bitowy lub uprościć w inny sposób, w zależności od potrzeb.

Potrzebujesz kilku stolików,

1 - Pytania (identyfikator pytania, typ wprowadzania, widoczne, typ pytania, tekst pytania, oczekiwane odpowiedzi ....)

2 - Odpowiedzi (identyfikator pytania, identyfikator użytkownika, identyfikator aktywności, odpowiedź ....)

3 - Użytkownicy (identyfikator użytkownika, nazwa użytkownika ......)

4 - Tabela do przechowywania działania pytania / odpowiedzi (identyfikator działania, dane / czas, identyfikator użytkownika)

Możesz również chcieć mieć tabelę, która określa pytania, które należy zastosować do każdego działania - pogrupowane według użytkownika lub kolekcji pytań. Klucze obce / podstawowe będą kolumnami o tej samej nazwie w wielu tabelach i powinny być indeksowane.

Jeśli używasz tej struktury, powinieneś być w stanie dodać pytanie lub użytkownika lub zmienić odpowiedź bez konieczności zmiany schematu lub kodu prezentacji - upewnij się, że kod prezentacji jest dynamicznie tworzony w czasie wykonywania - wystarczy dodać rekord w odpowiednim miejscu.

Podejście to może początkowo potrwać dłużej niż podejście zakodowane na stałe, ale będzie o wiele prostsze w utrzymaniu, ponieważ wystarczy zmienić dane, aby zmienić zachowanie.

(Wskazówka: aby utworzyć warstwę prezentacji, będziesz potrzebować zapytania, które wyświetli odpowiednie pytania do wyświetlenia, a następnie przejdzie przez ten zestaw wyników i wywoła metodę renderowania pytań na ekranie, przy czym metody, które należy wybrać, są odpowiednie prezentacja tego pytania [pole tekstowe, grupa radiowa itp.])