A variation of the first solution would be to use two new tables for answers that are sets or classes:
concept_answer_set
- concept_answer_set_id
- concept_id
- set_id
- <create and retire attributes>
concept_answer_class
- concept_answer_class_id
- concept_id
- class_id
- <create and retire attributes>
PRO: more normalized design, existing concept_answer (and related code) unaffected, distinguishes between a "choice list" and whether or not classes and/or sets are viable answers as well
CON: two new tables for data model
A variation of the first solution would be to use two new tables for answers that are sets or classes:
PRO: more normalized design, existing concept_answer (and related code) unaffected, distinguishes between a "choice list" and whether or not classes and/or sets are viable answers as well
CON: two new tables for data model
concept_answer_set
- concept_answer_set_id
- concept_id
- set_id
- <create and retire attributes>
concept_answer_class
- concept_answer_class_id
- concept_id
- class_id
- <create and retire attributes>
PRO: more normalized design, existing concept_answer (and related code) unaffected, distinguishes between a "choice list" and whether or not classes and/or sets are viable answers as well CON: two new tables for data model