But now let me complicate things: There are four questions, each with 5 or 10 possible choices, and multiple choices are allowed. Each update, the user answers all four questions.
So, I could have four separate tables, Q_1 to Q_4, each with 'update_id' and 'option' columns. To retirieve the selections of Monday, I have either four queries to create, prepare, execute and retrieve, or a four-table join to do. Versus one table with update_id and Q_1 to Q_4 columns, from which I do a single query and four splits.
I'm unsure that four queries, or a four table join, is going to be faster than a single query. Each query is a call to the DBI - an extra layer. Whereas a split is pure Perl.
But I agree that it's certainly not a purist's approach to database design.
In reply to Re^2: Perl or Mysql to store multiple choices?
by punch_card_don
in thread Perl or Mysql to store multiple choices?
by punch_card_don
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |