Обычно считается нормальным хранить строку запроса в базе данных?

Question

Если бы я должен был взять строку запроса из HTTP-запроса входящего запроса в веб-приложении, сохранить его непосредственно в базе данных MySql, а затем использовать его для пересоздания исходного URL-адреса запроса, будет ли это рассматриваться как ОК?

Мне интересно, есть ли какие-либо "ошибки", такие как специальные символы или многобайтовые символы в строке запроса, которые могут потребовать от меня кодирования данных или чего-то еще перед их сохранением.

Заранее спасибо.

РЕДАКТИРОВАТЬ : Мой конкретный вариант использования будет выглядеть примерно следующим образом. Хотя меня больше всего беспокоит вопрос о том, могут ли какие-либо специальные символы в строке запроса вызвать неожиданные проблемы.

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

Answer 1

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

Разработка:
Вместо хранения«? param1 = A¶m2 = B¶m3 = C» в поле с именем «querystring», вероятно, было бы лучше хранить A, B и C в трех полях, называемых «Param1, Param2 и Param3.

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

Answer 2

Зачем останавливаться на QueryString? Если вы хотите сохранить часть заголовка, почему бы не сохранить всю информацию заголовка, включая файлы cookie, данные публикации и т. Д.

Answer 3

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

INSERT INTO TABLE_OF_QUERIES (field1, field2, field3) VALUES (?,?,?);

Answer 4

Зависит от того, что на самом деле.

Если вы имеете дело с другим сервером, и строка запроса - это все, что вам нужно для идентификации запроса (ну, URI, но, вероятно, вы делаете ставку на остальныеБудучи статичным, возможно, проверьте это предположение), тогда идеально использовать в качестве идентификатора то, что по сути является идентификатором.

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

Если ваш код имеет дело с фактическими параметрами запроса, то, вероятно, нет.

Answer 5

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