Блог

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

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

#java #mysql #database #query-string

#java #mysql #База данных #строка запроса

Вопрос:

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

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

Заранее благодарю вас.

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

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

Комментарии:

1. вам следует подробнее остановиться на вашем варианте использования и привести пример

Ответ №1:

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

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

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

Комментарии:

1. Не могли бы вы, пожалуйста, подробнее остановиться на этом? Я не понимаю, что вы имеете в виду, говоря «хранить проанализированные значения вместо данных в формате querystring».

2. Спасибо за предложение! Я думал, что простое сохранение самой строки было своего рода «перспективным» в том смысле, что если в будущем к URL-адресу будут добавлены дополнительные значения строки запроса, мне не придется добавлять дополнительные поля для поддержки новых параметров.

3. @Jason: Это зависит от того, что означают параметры. Планируете ли вы извлекать их значения непосредственно из базы данных или планируете использовать строку исключительно для восстановления URL?

4. @Jack Рассмотрим эту строку запроса: name=Johnamp;age=30 . Тогда вы бы хранили не саму строку, а значения John для property name и 30 для свойства age .

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

Ответ №2:

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

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

Комментарии:

1. Хорошо, я предполагаю, для предотвращения атак sql-инъекций?

2. Да 🙂 И вам не придется беспокоиться о том, что другие кавычки или специальные символы внутри вашего сохраненного запроса будут мешать работе остальной части вашей оболочки insert

Ответ №3:

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

Комментарии:

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

Ответ №4:

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

Ответ №5:

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

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

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

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