When a user selects options 1,4,7,9, and 15 on Monday, either:
a) store it as 5 separate insertions of update_id - option pairs
b) first join them into a delimited string and do one insert
Then on retrieval, either:
a) select all rows with Monday's update ID (which means a while loop)
b) select a single row and split the retrieved string
I expect the first reaction to be "let the DB do its work; it's undoubtedly smarter and faster", but I suspect that the counter-intutitive ins in fact true: that the extra DBI layer, with its preparation and the retrieval loop, is going in fact ot be slower than a pure join or split, especially when it gets more complicate with multiple questions to store and therefore multiple queries to do.
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: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |