mysqli_stmt :: bind_param () - укажите другой тип данных, кроме «s» для каждого параметра

Question

mysqli_stmt :: bind_param () - укажите другой тип данных, кроме «s» для каждого параметра

0

У mysqli_stmt нет функции query_params(), я должен был написать свой собственный. Параметр arry связан с оператором bind_param(). Мне нужно указать типы переменных динамически. Я мог бы сделать это с чем-то вроде:

$sType = '';
foreach ($aParameters as $iIndex => $mParameter) {
  if     (is_string($mParameter)) {$sType .= 's';}
  elseif (   is_int($mParameter)) {$sType .= 'i';}
  elseif ( is_float($mParameter)) {$sType .= 'd';}
  elseif (  is_null($mParameter)) {$sType .= 's';}
  elseif (  is_bool($mParameter)) {
    $sType .= 'i';
    $aParameters[$iIndex] = boolval($mParameter);}
  else {
    // trow new Exception(...);
  }
}

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

Существуют ли какие-либо модификации для указания другого типа данных, чем "s" для каждого параметра?

EDIT: Я только что нашел эту тему SO, которая показывает, как использовать тип "b" и mysqli_stmt::send_long_data когда бинарный пакет превысит параметр max_allowed_packet. Я также прочитал, что это улучшит производительность над решениями, которые используют bin2hex() чтобы включить отправку байтовой строки в виде текста.

Code4R7 02 июль 2018, в 17:05

Источник

2

Абсолютно без причины, если вы делаете это таким образом. Причина в том, что вы всегда хотели, чтобы определенный параметр был связан как целое число или число с плавающей точкой. В MySQL бессмысленно определять тип связываемого объекта на основе типа данных переменной, которую вы связываете.
Devon 02 июль 2018, в 14:34
0

Рассматривать их всех , как s строки, если вы не кант в некоторых b двоичных на нулевую ссылке.
IncredibleHat 02 июль 2018, в 15:14
0

@IncredibleHat Да, до сих пор, кажется, что нижняя строка. Спасибо!
Code4R7 03 июль 2018, в 08:34

Показать ещё 1 комментарий

Теги:

php

mysql

mysqli

bindparam

1 ответ

Ещё вопросы

Абсолютно без причины, если вы делаете это таким образом. Причина в том, что вы всегда хотели, чтобы определенный параметр был связан как целое число или число с плавающей точкой. В MySQL бессмысленно определять тип связываемого объекта на основе типа данных переменной, которую вы связываете.
Рассматривать их всех , как s строки, если вы не кант в некоторых b двоичных на нулевую ссылке.
@IncredibleHat Да, до сих пор, кажется, что нижняя строка. Спасибо!

Bill Karwin · Answer 1 · 2018-07-02T13-08-00.000Z

1

Единственный раз, когда я нашел важным использовать целочисленный параметр, - это предложение LIMIT.

SELECT
...
LIMIT ?, ?

MySQL не принимает цитированные строковые литералы в этом контексте и не принимает параметры со строковым типом. Вы должны использовать целое число.

См. Параметрированный запрос PDO и предложение LIMIT - не работает для моих тестов. Это был вопрос о PDO, и я не тестировал mysqli, но я считаю, что требование MySQL на стороне сервера для использования целочисленных параметров в этом случае. Поэтому он также должен применяться к mysqli.

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

Bill Karwin 02 июль 2018, в 13:08

0

Спасибо, что покопались в моем вопросе. Я протестировал предложение LIMIT, но не могу воспроизвести его с помощью PHP 7.0, клиент MySQLi подключен к MariaDB 10.0. Когда я выпускаю call_user_func_array([$rStmt, 'bind_param'], $aCall); (Массив $ aCall - это обходной путь для ошибки PHP # 44139.) Тогда предложение LIMIT принимает строки как тип.
Code4R7 02 июль 2018, в 17:31
0

Хорошо, возможно, это просто проблема при использовании PDO с эмулированной подготовкой, как я написал в другом ответе, с которым я связан.
Bill Karwin 02 июль 2018, в 17:34
0

Я думаю, что вы правы в отношении PDO из-за этого вопроса.
Code4R7 02 июль 2018, в 17:37
0

Да, LIMIT '10', '20' не является допустимым синтаксисом MySQL. Необычное поведение эмулированных приготовлений с помощью PDO может привести к такому синтаксису. Лучше не использовать эмулированные препараты.
Bill Karwin 02 июль 2018, в 17:39
0

Хороший колл от Ints в LIMIT. Наверное, я никогда не думал об этом, так как никогда не использовал пользовательский ввод непосредственно в выражении LIMIT. Я всегда получаю это программно из списка / выбора страниц из белого списка.
IncredibleHat 03 июль 2018, в 13:42
0

Это должно быть причиной, почему я предпочитаю mysqli, а не PDO =]
Code4R7 09 июль 2018, в 19:02
0

@ Code4R7, я предпочитаю PDO, если эмулированная подготовка отключена. Мне не нравится, как MySQL делает привязку параметров. PDO имеет более приятное использование, вы можете передать массив значений для execute() .
Bill Karwin 09 июль 2018, в 19:05
0

@BillKarwin Я намекал на это видео , но вы абсолютно правы с массивом значений, поэтому мне пришлось написать свой собственный query_params() . Я думаю, что PDO - это общий соединитель для общих ситуаций. Вы можете использовать любую базу данных. В моем случае фреймворк привязан к MariaDB, поэтому MySQL будет лучшим выбором. Хотя я бы хотел перейти на PostGres, когда это позволяет мой технологический стек.
Code4R7 10 июль 2018, в 07:01
0

@ Code4R7, имеет смысл иметь один API для всех баз данных SQL. Как модель JDBC, ODBC, Perl DBI или Go's db. Тот факт, что PHP решил создать совершенно уникальное расширение и API для каждой марки базы данных, был плохим решением (как многие в PHP).
Bill Karwin 10 июль 2018, в 15:40
0

@BillKarwin Давайте согласимся не соглашаться здесь. Пожалуйста, позвольте мне экстраполировать то, что вы говорите. Похоже, что плохой дизайн - иметь несколько языков на стороне веб-сервера, таких как PHP, Ruby, Java и так далее. и что язык, который объединяет их всех, как HAXE , имеет смысл. Поэтому уникальные языки - это плохое решение? Я согласен, что PDO имеет смысл во многих случаях. Но когда вы хотите водить машину Формулы-1, обычный водитель не подойдет. Также доступность - это другое (огромное) качество, и было время, когда PDO не было доступно. Прагматичный подход, PHP говорит об этом на своем сайте.
Code4R7 10 июль 2018, в 19:22
0

Это правда, PDO все еще был проектом PECL, когда был выпущен PHP 5.0, но он стал стандартным расширением PHP в PHP 5.1. Если вы хотите выбрать технологию, основанную на том, что было доступно до 2005 года, будьте моим гостем.
Bill Karwin 10 июль 2018, в 19:38
0

Мы все знаем, что PDO использует MySQLi в фоновом режиме. А PDO не совсем святой Грааль, например, он (пока) не преобразует фактические запросы SQL в разновидности различных баз данных. И PDO измеряется чуть-чуть медленнее, чем MySQLi. К счастью, здесь перечислены самые важные различия, на которых должно основываться решение.
Code4R7 10 июль 2018, в 20:18

Показать ещё 10 комментариев