Para que serve PDO::PARAM_

[tiujhou 7]

Boa tarde...

 

Estou criando uma class com PDO, e estou com dúvida no uso dessas CONSTANTES:

 

– PDO::PARAM_STR – para valores strings, datas, horas…
– PDO::PARAM_INT – para valores inteiros
– PDO::PARAM_BOOL – para valor booleano (true ou false)
– PDO::PARAM_NULL – valor nulo (null)
– PDO::PARAM_LOB – representa valores de grande quantidade de dados
– PDO::PARAM_STMT – representa um conjunto de registros, atualmente não é suportado por nenhum driver
– PDO::PARAM_INPUT_OUTPUT – especifica que é um parâmetro de entrada e saída para “stored procedures”

 

O terceiro parâmetro é uma constante do PDO que informa ao sistema que tipo de dado você está adicionando ao sql.

 

Qual é o beneficio deu informar qual o tipo de dado que estou passando?

 

Pois pelo que entendi, por default é PARAM_STR... o que eu ganharia passando os valores se são INT, BOOL ETC?

[Matheus Tavares 167]

Falando sobre o MySQL:

 

Tratando o parâmetro como inteiro (PARAM_INT):

SELECT * FROM `tabela` WHERE `id` = 5

Tratanto o parâmetro como string (PARAM_STR):

SELECT * FROM `tabela` WHERE `id` = '5'

Na prática o resultado é o mesmo. A consulta irá retornar o registro com id 5.

Mas o certo é enviar parâmetros inteiros sem o uso de aspas. E é para isso que serve o envio das constantes, para enviar cada tipo de forma correta ao banco.

 

Ele envia como string por padrão pq se você não configurar nada, não vai dar problema. Se você enviasse uma string com tipo de inteiro, a consulta iria ficar assim:

SELECT * FROM `tabela` WHERE `id` = bla bla bla

Ou, ainda mais provável, o PDO iria fazer um cast dos dados, gerando um valor nulo:

SELECT * FROM `tabela` WHERE `id` = 0

Enfim... assim como no PHP temos tipos, no banco de dados também. As constantes que você citou apenas fazem uma analogia entre os tipos do PHP para o banco.

 

Espero ter ajudado. :thumbsup:

[tiujhou 7]

Ajudou muito sua resposta... Mas será que na questão de performance melhora algo?

[Gabriel Heming 766]

No MySQL você realmente não verá grande utilidade, mas em outros SGBDs você verá.

 

Por exemplo, no PostgreSQL, o código abaixo funciona perfeitamente:

$pdoStatement->bindValue(':boolean' , true);

Já esse código não:

$pdoStatement->bindValue(':boolean' , false);

Pois a conversão padrão é para string, e false convertido para string não é bem interpretado pelo SGBD.

Por isso é necessária a inserção do parâmetro informando que é um boolean:

$pdoStatement->bindValue(':boolean' , false , PDO::PARAM_BOOL);

Já, se o valor false for inserido como string, também funcionará.

$pdoStatement->bindValue(':boolean' , 'false');

Mas uma string "escrita" false, não possui o mesmo peso/valor que a booleana false.

 

Quanto a performance, acredito que há um ganho sim, uma vez que o cast type é explícito (e não implícito como por padrão). Mas o ganho deve ser tão insignificante, que se torna imperceptível.

[tiujhou 7]

Muito boa a resposta dos 2, nem irei marcar como resolvido, caso alguém tenha algo mais para contribuir... ATT