Desain basis data kuesioner - jalan mana yang lebih baik?

Saya memiliki SATU halaman html panjang, beberapa set pertanyaan dibagi menjadi beberapa bagian kecil (sekitar 15 sub-bagian dalam satu halaman), total pertanyaan sekitar 100 pertanyaan: bervariasi dari input, pilihan ganda, kotak centang, tombol radio, textarea, dan unggah file. Satu pertanyaan dapat berisi banyak jawaban yang diperoleh baik dari kelompok kotak centang, kelompok daftar pilih, kelompok multi-pilih, atau semuanya digabungkan menjadi satu jawaban. Saya pikir saya akan menggunakan desain database ini di bawah ini tetapi menemukan belakangan ini bahwa itu bukan pendekatan yang baik.

1. Satu pelanggan hanya dapat memiliki satu set pertanyaan: satu pelanggan per 100 pertanyaan.
2. Untuk pendekatan lama saya tidak menyimpan pertanyaan dalam database tetapi menetapkan konstanta dalam pengkodean PHP. Masalahnya adalah saya harus membandingkan pertanyaan dalam PHP untuk menyelaraskannya dengan jawaban di database. Jika satu pertanyaan telah diubah / dihapus / dipindahkan dari PHP, saya pasti akan tersesat untuk mencocokkannya dengan jawaban di basis data Kuisioner. Solusi yang lebih baik?
3. Apakah saya dapat menyimpan beberapa jawaban yang diperoleh dari berbagai elemen dalam bentuk menjadi satu bidang sebagai satu jawaban? Bagaimana saya bisa mengambil bidang ini dan menampilkannya lagi untuk dilihat pelanggan pada formulir?
4. Opsi mana di bawah ini yang harus saya pilih?

OPSI 1: Pendekatan Lama (1 tabel)

TABEL: Kuisioner

• ID (PK)
• ID Pelanggan
• Status
• A1
• A2
• A3
• .
• .
• .
• A100

OPSI 2: Pendekatan Baru (2 tabel)

TABEL: Pertanyaan

• QID (PK)
• Pertanyaan (varchar)

TABEL: Jawab

• BANTUAN (PK)
• ID Pelanggan
• QID (int)
• Jawab (varchar)

Atau OPSI 3?

Tentunya jangan kode keras kuesioner Anda. Gunakan database relasional atau file xml. Saya mengusulkan tabel berikut

• Questionnaire: Deskripsi umum kuesioner. Judul, nama survei, tanggal rilis kuesioner, versi, dan sebagainya.

• Section: Bagian kuesioner dibuat. Jumlah bagian, judul bagian, deskripsi.

• Question: Pertanyaan milik bagian. Jumlah pertanyaan, teks pertanyaan, deskripsi, jenis pertanyaan (teks, pilihan ganda, dll.).

• Question_Choice: Jawaban yang mungkin milik pertanyaan yang terkait dengan kotak centang tunggal, tombol radio, dan sebagainya. Teks pilihan, nomor pilihan, urutan.

• Respondent: Orang-orang yang menjawab pertanyaan. Data pribadi, nomor pengguna.

• Interview: Wawancara atau tes atau survei (tergantung pada sifat kuesioner) milik satu responden dan satu kuesioner. Jika responden selalu dapat menjawab hanya satu kuesioner (atau jika survei itu anonim), tabel ini sudah usang dan dapat digabung dengan tabel Responden. Tanggal wawancara (atau tanggal tes atau tanggal survei), pewawancara (jika berlaku).

• Answer: Jawaban milik satu wawancara (atau responden, lihat di atas) dan satu pertanyaan. Teks jawaban (untuk pertanyaan jenis teks), pilihan (untuk tombol radio).

• Answer_Choice: Pilihan milik satu Jawaban dan satu Pertanyaan_Pilihan ketika beberapa pilihan dapat diperiksa.

Ini adalah pendekatan yang sangat dinormalisasi; Namun, Anda dapat memutuskan untuk menggabungkan pilihan menjadi satu string atau menyimpannya sebagai pola bit atau menyederhanakannya dengan cara lain tergantung pada kebutuhan Anda.

Anda perlu beberapa tabel,

1 - Pertanyaan (id pertanyaan, tipe input, terlihat, jenis pertanyaan, teks pertanyaan, jawaban yang diharapkan ....)

2 - Jawaban (id pertanyaan, id pengguna, id aktivitas, jawaban ....)

3 - Pengguna (id pengguna, nama pengguna ......)

4 - Tabel untuk menyimpan aktivitas tanya / jawab (id aktivitas, data / waktu, id pengguna)

Anda juga mungkin ingin memiliki tabel yang menentukan pertanyaan yang harus diterapkan untuk setiap kegiatan - baik dikelompokkan berdasarkan pengguna atau mungkin koleksi pertanyaan. Kunci asing / primer akan menjadi kolom yang memiliki nama yang sama di beberapa tabel dan harus diindeks.

Jika Anda menggunakan struktur ini, Anda harus dapat menambahkan pertanyaan atau pengguna atau mengubah jawaban tanpa harus mengubah skema atau kode presentasi Anda - pastikan bahwa kode presentasi dibuat secara dinamis pada saat run time - Anda hanya perlu menambahkan catatan di tempat yang tepat.

Pendekatan ini mungkin membutuhkan waktu lebih lama untuk dikembangkan daripada pendekatan yang dikode keras, tetapi akan lebih mudah untuk dipertahankan karena Anda hanya perlu mengubah data untuk mengubah perilaku.

(Kiat, untuk membuat lapisan presentasi Anda, Anda akan memerlukan kueri yang menampilkan pertanyaan yang sesuai untuk ditampilkan, kemudian mengulangi set hasil ini dan memanggil metode untuk membuat pertanyaan di layar, metode untuk memilih yang sesuai dengan presentasi pertanyaan itu [kotak teks, grup radio, dll])