Я не думаю, что достаточно времени было уделено рассмотрению схемы, поднятому в исходном сообщении. Итак, вот что нужно учесть новичкам.
Допустим, вы создали это решение. Все ваши второстепенные значения объединяются в одно значение и хранятся в базе данных. Вы действительно экономите [немного] места в своей базе данных и немного времени на кодирование.
Теперь давайте представим, что вы должны выполнять частую и простую задачу добавления нового флажка между текущими флажками 3 и 4. Ваш менеджер по разработке, заказчик, все, кто ожидает, что это будет простое изменение.
Итак, вы добавляете флажок в пользовательский интерфейс (простая часть). Ваш циклический код уже будет объединять значения независимо от количества флажков. Вы также полагаете, что поле вашей базы данных - это просто varchar или другой строковый тип, так что это тоже должно быть хорошо.
Что происходит, когда клиенты или вы пытаетесь просмотреть данные до изменения? По сути, вы сериализуете слева направо. Однако теперь значения после 3 отличаются на 1 символ. Что вы собираетесь делать со всеми имеющимися у вас данными? Собираетесь ли вы написать приложение, вытащить все это обратно из базы данных, обработать, чтобы добавить значение по умолчанию для новой позиции вопроса, а затем сохранить все это обратно в базу данных? Что произойдет, если у вас будет несколько новых значений с разницей в неделю или месяц? Что, если вы переместите местоположения и jQuery обработает их в другом порядке? Все ваши данные закрыты и должны быть повторно обработаны, чтобы переупорядочить их.
Вся концепция НЕ обеспечивать тесные отношения «ключ-значение» - лудакрис, и рано или поздно у вас возникнут проблемы. Тем из вас, кто задумывается об этом, пожалуйста, не надо. Другие предложения по изменению схемы в порядке. Используйте дочернюю таблицу, дополнительные поля в основной таблице, таблицу вопросов и ответов и т. Д. Просто не храните немаркированные данные, если структура этих данных может измениться.