Отслеживание информации на многих страницах для веб-сайта

Question

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

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

Answer 1

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

Возможно, вы захотите сохранить данные в более свободной форме, например, XML в одном столбце. Это позволит вам поддерживать сложные структуры данных в простой схеме данных, но затруднит запрос данных (если ваша база данных не поддерживает типы столбцов xml, как это делают большинство современных корпоративных баз данных).

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

Хранение промежуточных данных в БД также позволяет пользователю переходить с одной страницы на другую и повторно посещать прошлые страницы.

Скрытые поля также являются хорошим подходом, но они не позволят пользователю вернуться позже.

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

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

Answer 2

Я бы придерживался сохранения данных в сеансе, поскольку на этом этапе они более или менее временны: что бы вы сделали, если пользователь не заполняет формы? Вам придется регулярно проверять таблицу SQL на наличие незавершенных данных, что усложняет работу всего приложения.

Кстати, есть причина истечения сеанса, а именно безопасность. И вы можете определить себя, когда сессия истекает.

Answer 3

Ааа, хороший вопрос.

Я обнаружил, что это отличный способ справиться с этим (если он линейный). Следующее будет работать особенно хорошо, если вы включаете различный контент (страницы) в одну страницу PHP (например, MVC). Однако, если вам нужно перейти от URL к URL, это может быть затруднительно, потому что вы не можете POST через перенаправление (ну, вы можете, но ни один браузер не поддерживает его).

Вы можете заполнить детали.

$data = array();
//or//
$data = unserialize(base64_decode($_POST['data']));


// add keys to data


// serialize
$data = base64_encode(serialize($data));


<input type="hidden" name="data" value="<?= htmlspecialchars($data, ENT_QUOTES); ?>" />

Answer 4

Почему бы просто не передать вещи в скрытых параметрах?