Как сделать пошаговую форму с записью данных в БД?

Question

[Иван Медведев]

Есть задача написать форму регистрации с несколькими шагами. Вот прямо как на этом сайте: https://babules.com.ua/

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

Подскажите, где искать решение? Куда хранить данные из формы? У меня напрашивается вариант - записывать в БД. Правильно ли я мыслю?

Answer 1

[Арсений Матыцин]

Тут много описано про сессии и да, это это корректный подход при незавершенной базовой регистрации.

А вот если у тебя уже есть в базе логин и пасс пользователя, по которому можно зайти. Или привязка к социальной сети, то тут помогут триггеры в базе в виде boolean-значений. Скажем:

user сущность с колонками:
1. is_active — так можно делать ленивое удаление.
2. is_confirmed — подтвердил почту.

И т.д. Так, ты сможешь проверять в роуте текущее состояние и в зависимости от сценария пускать в ту или иную сторону. Например при is_confirmed == false → вместо ЛК отправлять на страницу с кнопкой «выслать ключ еще раз».

Я думаю ты видел такое на сервисах.

Answer 2

[tempick]

Есть несколько вариантов. Я не эксперт (исключительно любитель), так что не утверждаю, что хотя бы один из них реально правильный.

Вариант 1. Создание сессии на стороне сервера, сохранение данных из формы в самой сессии.
Вариант 2. Создание сессии, но сохранение данных в БД. Присваиваем уникальный ID пользователю (как правило, это решает за нас атрибут AUTO_INCREMENT в бд) и в сессии храним лишь этот id. При повтором открытии формы пользователем берем из сессии его id, ищем в бд, и если есть уже заполненные им поля формы, то подставляем эти значения в форму.
Вариант 3. Без сервера и бд. Сохраняем все введенные данные с помощью js в LocalStorage. При повторном заходе клиента, просто смотрим, есть ли в хранилище введенные им данные, и если есть, подставляем в форму. Но если в форме есть поля с загрузкой файлов, то в этом случае, нужно будет их хранить, например, в base64.

В первом и третьем варианте подразумевается, что в после заполнения всех полей формы все данные всё равно будут записаны в БД.

UPD: тут зависит от конкретного случая. Если, например, на первом этапе пользователь воодит свой E-mail, и он вам понадобится, например, для рассылок, независимо от того, заполнил он форму полностью или нет - то лучше второй вариант. Если же вам не нужны данные пользователя, пока он не заполнит все поля - то третий вариант будет проще и лучше. Ну и первый вариант в этом случае тоже подойдет

Comments

[Иван Медведев]

Мне как раз нужны данные, введенные пользователем на первом этапе, именно для рассылок. Где почитать про создание сессии и т.д.?

[tempick]

Иван Медведев, в гугле)

Answer 3

[alix_xil]

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

Answer 4

[Евгений Залецкий]

Через сессию это можно реализовать. Исправьте, если я не прав в этом варианте. Реализовать сессию можно через php.

Answer 5

[Константин Боровик]

Исходя из вашего описания проблемы, я могу посоветовать несколько вариантов:
1. БД. Вариант хороший, НО что делать с "битыми", недоделанными аккаунтами. Они будут просто захламлять базу, потому что уже на первом этапе регистрации вам придётся создавать юзера.
2. Сессия. Вариант плохой, хотя бы потому что это вещь, которая недолговечна. Обычно сессия ну максимум пару часов держится (зависит от настроек приложения).
3. Куки. Вариант лучше сессии, потому что вы сами можете установить время жизни и они хранятся на стороне клиента.
4. localstorage. Вариант сравнимый с куки. Не имеет времени жизни, поэтому долговечен и тоже хранится на стороне клиента.
Два последних варианта очень хороши для ваших целей, но не слишком безопасны, в любом случае вам решать, что использовать. Возможно есть и другие способы, но это всё, что мне пришло в голову на лету.

Comments

[tempick]

Да, я написал примерно то же самое. Тут скорее зависит от конкретной задачи. Но хранение в бд всё-таки надежнее. И если сайт небольшой, где за год максимум 1-2 млн регистраций будет, то ничего страшного не будет от "хлама". И тем более, можно периодически (например, по крону) просто удалять записи, где заполнены не все поля, и которые в последний раз обновлялись N дней (недель, месяцев...) назад.

[Арсений Матыцин]

НО что делать с "битыми"

Чистить по сроку давности и триггерам.