Как хранить части данных формы, когда они находятся на отдельных страницах?

Question

Всякий раз, когда я готовлю длинную форму для клиента, я всегда хочу разделить ее на отдельные страницы, чтобы посетителю не приходилось заполнять все это, а делал это поэтапно.

Что-то вроде:

Step 1  >  Step 2  > Step 3 > Thank You!

Я никогда не делал этого по одной причине: я не знаю, как эффективно хранить данные из отдельных шагов? Под эффективностью я имею в виду, как хранить его, поэтому, когда посетитель решает не завершать его на шаге 3, все данные удаляются.

Я придумал несколько способов, как это можно решить, но я просто не убежден ни одним из них:

1. Хранение данных формы в базе данных
   Я могу представить таблицу со столбцами, представляющими каждый вопрос, с последним столбцом, представляющим значение bool независимо от того, была ли форма заполнена или нет?
   Но мне пришлось бы время от времени выполнять очистку таблицы (возможно, даже каждый раз, когда она обновляется новыми данными?) И удалять все записи с помощью complete = 0.

2. Сохранить данные формы в данных сеанса.
   Это, с другой стороны, не требует хранения данных в базе данных (в зависимости от того, как обрабатываются сеансы), и вся информация будет в Cookie. Но что, если браузер не поддерживает файлы cookie или пользователь отключил их (редко, но бывает), или если в форме есть файловые вложения, это не нужно.

3. echo данные формы с предыдущей страницы как <input type="hidden"> на следующей странице
   Да, я знаю, что это довольно глупая идея, но это альтернатива. Плохо, но это так.

Опция 1 кажется лучшей, но я чувствую, что нет необходимости хранить временные данные в БД. А что, если это станет очень популярной формой, заполняемой многими посетителями? Количество обновлений / удалений может быть огромным?

Я хочу знать, как вы справляетесь с этим.

---

Редактировать

Дэвид задал хороший вопрос. Какую технологию я использую?
Я лично использую PHP + MySQL, но я чувствую, что это более общий вопрос. Пожалуйста, поделитесь своими решениями независимо от того, какую серверную технологию вы используете, так как я уверен, что концепция может быть так или иначе адаптирована к различным технологиям.

Answer 1

Я думаю, что выбор между вариантами 1 и 2 сводится к тому, сколько данных вы храните. Я думаю, что в большинстве случаев объем данных, которые вы собираете в форме, будет довольно небольшим (несколько килобайт). В этом случае, я думаю, хранение этого в данных сеанса - это путь. Передача такого количества данных туда-сюда не так уж и сложна. Кроме того, если ваши пользователи не находятся на компьютерах, где действует строгая политика безопасности, приложение должно работать. Если вы четко указали требования к странице, пользователи могут решить, хотят они продолжить или нет.

Если вы храните большие объемы данных для формы, тогда база данных будет лучше, поэтому вам не нужно передавать данные взад и вперед. Тем не менее, я думаю, что это будет довольно редкая ситуация. Даже если приложение позволяет загружать файлы, вы можете сохранить их во временном местоположении и записать их в базу данных только после заполнения формы. Другая ситуация, когда вам может потребоваться использовать базу данных, - это если ваша форма должна поддерживать пользователя, который уходит и возвращается позже, чтобы возобновить форму.

Answer 2

Я согласен, что вариант 1 является лучшим, потому что он имеет несколько преимуществ по сравнению с другими 2:

• Если данные сохраняются, пользователи могут вернуться позже и продолжить процесс
• Ваша кодовая база будет намного чище с добавочным сохранением, и это устраняет необходимость в 1 крупномасштабной операции сохранения
• Ваш отпечаток ноги (каждый запрос страницы) будет легче, чем вариант 3

Если вы беспокоитесь о производительности, вы можете поставить в очередь данные для сохранения, поскольку нет необходимости сохранять их практически в реальном времени.

Редактирование, чтобы устранить ошибочное представление: данные внутри сессий PHP по умолчанию НЕ хранятся в файлах cookie и способны хранить много данных без чрезмерных затрат.

Answer 3

Нет ничего плохого в том, чтобы взять данные POST из предыдущего шага и добавить скрытые input элементы. Просто возьмите все данные POST с предыдущей страницы, которые вас интересуют, и введите их в форму текущей страницы. Таким образом, вам не нужно беспокоиться об использовании постоянного хранилища в любой форме, будь то на стороне клиента или на стороне сервера.

Каковы недостатки? Что на странице много лишних элементов? Не то, что пользователь видит. Все, что вам нужно сделать, это добавить элемент для каждого ввода, который вы просите пользователя (на каждой странице, если вы хотите, чтобы пользователь мог вернуться назад). Кроме этих элементов, которые не дают визуального беспорядка, нет ничего лишнего.

Существует также тот факт, что все данные формы должны будут передаваться при каждой загрузке страницы. Конечно, но это, вероятно, будет быстрее, чем поиск в базе данных, и вам не нужно беспокоиться об избавлении от устаревших данных.

Answer 4

Честно говоря, просто используйте базу данных, как в варианте 1, и перестаньте беспокоиться об объемах данных. Серьезно, если ваш сайт настолько успешен, что становится проблемой, тогда вы сможете найти нового вампиона, чтобы справиться.

Answer 5

Я бы пошел с номером 2, но использовать куки только для идентификации пользователя. На самом деле данные сеанса должны храниться на вашем сервере, а cookie просто предоставляет ключ поиска для объекта сеанса, который содержит все детали.

Если сайт становится популярным и ему нужно работать на более чем одном веб-сервере, данные вашего сеанса в любом случае необходимо будет сохранить в какой-либо базе данных. В этом случае вам потребуется база данных, которая может обрабатывать огромное количество транзакций.

Примечание: Я согласен, что это независимый от платформы вопрос. Пользователи переполнения стека предпочитают видеть код в вопросах и предпочитают давать код в ответах, поэтому я обычно спрашиваю, на каком языке кто-то использует.