Menyimpan data formulir dinamis dalam DBMS, mencari pendekatan yang optimal

Anda telah menghadapi masalah umum:Mencoba menggunakan sesuatu yang statis (basis data dengan struktur yang telah ditentukan sebelumnya) untuk sesuatu yang dinamis (sekelompok kumpulan data individual yang hanya memiliki satu kesamaan:mereka berasal dari formulir). Apa yang Anda inginkan bisa dilakukan dengan database tetapi akan jauh lebih mudah untuk melakukannya tanpa, namun karena saya berasumsi Anda benar-benar ingin menggunakan database untuk ini, inilah yang akan saya lakukan:

• Anda memiliki document (atau kuesioner ) yang berisi beberapa questions . Keduanya cukup umum dan memerlukan tabelnya sendiri, seperti yang telah Anda lakukan sejauh ini.
• Setiap pertanyaan memiliki type yang mendefinisikan pertanyaan macam apa itu (pilihan ganda, bentuk bebas, pilih satu... ) dan tentu saja pertanyaannya juga memiliki options . Jadi itu dua meja lagi. Alasannya di sini adalah bahwa memisahkan ini dari pertanyaan aktual memungkinkan adanya tingkat abstraksi tertentu dan kueri Anda akan tetap sederhana meskipun mungkin terlalu lama.

Jadi, setiap dokumen memiliki 1..n pertanyaan, setiap pertanyaan memiliki 1 jenis dan 1..n opsi. Melewati sedikit, inilah yang saya pikirkan dengan tabel tautan dll.

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

Desain semacam ini memungkinkan beberapa hal:

• Pertanyaan itu sendiri dapat digunakan kembali, sangat berguna jika Anda membuat "jawaban x pertanyaan acak ini dari kumpulan y pertanyaan generik ".
• Jenis baru dapat ditambahkan dengan mudah tanpa merusak yang sudah ada.
• Anda selalu dapat menavigasi melalui struktur dengan cukup mudah, misalnya "Apa nama dokumen untuk jawaban pertanyaan tunggal yang saya miliki ini? " atau "berapa banyak orang yang salah menjawab satu pertanyaan ini?"
• Karena jenisnya dipisahkan, Anda dapat membuat UI (web) yang mencerminkan status dalam database dengan mudah - lebih baik lagi, jika jenisnya berubah, Anda bahkan tidak perlu menyentuh kode UI sama sekali.
• Karena setiap opsi yang mungkin untuk sebuah pertanyaan adalah barisnya sendiri di QuestionOptions tabel, Anda bisa mendapatkan nilai sebenarnya dengan sangat mudah.

Masalah yang jelas dengan ini adalah bahwa hal itu memerlukan sambungan yang cukup ketat antara tabel untuk integritas dan akan menyusahkan untuk menjalankan dengan benar di awal. Juga karena value di QuestionOptions adalah varchar, Anda harus dapat mengurai banyak hal dan Anda bahkan mungkin ingin memperkenalkan bidang lain untuk petunjuk konversi.

Semoga ini bisa membantu meskipun Anda sama sekali tidak setuju dengan solusi saya.