When to seperate database column meaning (generic columns) - database

Question

I'm designing a feedback system for a site which has approximately 20 questions, but those questions may change each year and trying to consider the best design.
The simplest way is to map each question into a column, but this would require creating a new table each year and changing the application code which isn't sensible at all.
The second option is to separate the columns from the meaning and have a second table that applies meaning, i.e.
Table1: (row per survey) Table2: (row per questionnaire type)
QuestionID AnswerID
Question1 QuestionID
Question2 Answer1
... ....
Question20 Answer20
The third option I can think of is to completely separate each aspect like:
Table1: Table2: Table3: Table4:
QuestionID AnswerID MatchTableID SetID
QuestionValue AnswerValue QuestionID FeedbackSet
AnswerID QuestionID
Which gives it the benefit of scalability, but it may be excessive for something changing at most once a year for a few hundred records and i'm not sure if that doesn't feel a bit too much like an Entity-Attribute-Value design.
I'd appreciate any comments on what is considered to be best practice here and what is considered acceptable practice.

Answer 1

You might want to just keep it simple and go with a classic relational setup.
The models:
class Question < ActiveRecord::Base
has_many :replies
has_many :answers
belongs_to :questionnaire
end
class Answer < ActiveRecord::Base
belongs_to :question
has_many :replies
end
# A collection of questions
class Questionnaire < ActiveRecord::Base
has_many :questions
has_many :replies, through: :questions
end
# A user reply to a question
# acts as a many to many join table
class Reply < ActiveRecord::Base
belongs_to :question
belongs_to :answer
end
The schema:
ActiveRecord::Schema.define(version: 20160215124045) do
create_table "answers", force: :cascade do |t|
t.text "text"
t.integer "question_id"
t.datetime "created_at", null: false
t.datetime "updated_at", null: false
end
add_index "answers", ["question_id"], name: "index_answers_on_question_id"
create_table "questionnaires", force: :cascade do |t|
t.datetime "created_at", null: false
t.datetime "updated_at", null: false
end
create_table "questions", force: :cascade do |t|
t.text "text"
t.integer "questionnaire_id"
t.datetime "created_at", null: false
t.datetime "updated_at", null: false
end
add_index "questions", ["questionnaire_id"], name: "index_questions_on_questionnaire_id"
create_table "replies", force: :cascade do |t|
t.integer "question_id"
t.integer "answer_id"
t.datetime "created_at", null: false
t.datetime "updated_at", null: false
end
add_index "replies", ["answer_id"], name: "index_replies_on_answer_id"
add_index "replies", ["question_id"], name: "index_replies_on_question_id"
end
Yeah its a lot of tables - but this gives you a great deal of flexibility without dealing with the hassle that is key value tables. And its also much faster to build than some hacky attempt at a dynamic schema.
Its also really easy to pull out metrics if needed.
This example makes quite a few assumptions:
The questions are multiple choice - not write in. You can quite simply adapt it by storing the write-ins on the replies table.
The relation between question and questionnaire is one-to-one. Use a join table and HABTM relationship or has_many through: if need to be able to reuse questions on multiple questionnaires.