Когда *не* для использования подготовленных операторов?

Я нашел этот пост DevTicks Рикардо Хека, который решил мою проблему. введите ссылку для более подробного описания.

Я изменил настройки отображения следующим образом:

    "mappings": {
    "_doc": {
      "properties": {
        "title": {
          "type": "text",
          "analyzer": "autocomplete",
          "search_analyzer": "autocomplete_search",
          "fields": {
            "ngram": {
              "type": "text",
              "analyzer": "autocomplete"
            }
          }
        }
      }
    }
  }

И теперь я получаю документ «آلمان خوب است», выполняя поиск по термину "آلمانی".

34
задан Community 23 May 2017 в 10:30
поделиться

6 ответов

Я думаю, что Вы хотите PDO:: ATTR_EMULATE_PREPARES. Это выключает собственную базу данных, подготовил операторы, но все еще позволяет привязке запроса предотвращать внедрение SQL и сохранять Ваш sql опрятным. Из того, что я понимаю, PDO:: MYSQL_ATTR_DIRECT_QUERY выключает привязку запроса полностью.

17
ответ дан rick 27 November 2019 в 16:32
поделиться

Сегодняшнее правило разработки программного обеспечения: , если это не собирается делать что-нибудь для Вас, не используйте его.

25
ответ дан chaos 27 November 2019 в 16:32
поделиться

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

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

я не знаком с PDO, но я держал пари, что он обеспечивает механизм для выполнения параметрических запросов со значениями, данными в том же вызове функции, если Вы не хотите готовиться, затем работаете как отдельный шаг. (например, Что-то как run_query("SELECT * FROM users WHERE id = ?", 1) или подобный.)

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

15
ответ дан Dave Sherohman 27 November 2019 в 16:32
поделиться

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

шанс, что Ваше настраиваемое решение небезопасно, довольно высок. Используйте подготовленные операторы. Необходимо поддержать меньше кода тот путь.

8
ответ дан Alphager 27 November 2019 в 16:32
поделиться

Преимущества подготовленных операторов следующие:

  • каждый запрос только компилируется однажды
  • , mysql будет использовать более эффективный транспортный формат для отправки данных в сервер

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

Лично я не обеспокоился бы. Псевдоподготовленные операторы, вероятно, будут полезны для безопасного заключения в кавычки переменной, которое они, по-видимому, обеспечивают.

7
ответ дан ʞɔıu 27 November 2019 в 16:32
поделиться

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

я имею, столкнулся с той же проблемой, как у Вас и меня было мое собственное резервирование, таким образом, вместо того, чтобы использовать PDO я закончил тем, что писал свой собственный легкий слой базы данных, который поддерживал, готовится и стандартные операторы и выполненный корректный выход (предотвращение внедрения SQL) в обоих случаях. Одно из моих других схватываний с готовится, то, что иногда более эффективно добавить некоторый ненеобязательный вход к оператору как... ГДЕ идентификатор В (1, 2, 3...).

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

2
ответ дан Elijah 27 November 2019 в 16:32
поделиться
Другие вопросы по тегам:

Похожие вопросы: