Porque Usar E Como Usar O Pdo Em Suas Aplicações Php

[Bruno_Quaresma 3]

Um artigo breve que eu escrevi dando uma pequena introdução ao PDO e como utilizar seus recursos para deixar suas aplicações mais seguras.

Porque usar?

 

Além de ser bastante seguro o PDO é também bastante prático.

 

Para usá-lo basta apenas instanciar um objeto PDO com as configurações de acesso ao banco de dados.

 

<?php

$db = new PDO('mysql:host=localhost;dbname=nome_banco',$usuario,$senha);

?>

 

Organizando melhor o código ele ficará assim

 

 
<?php

//CONFIGURAÇÕES
$type_db = 'mysql';
$host = 'localhost';
$dbname = 'nome_do_banco';
$usuario = 'usuario';
$senha = 'senha';

$db = new PDO($type_db.':host='.$host.';dbname='.$db_name,$usuario,$senha);

?>

 

Agora podemos fazer nossas consultas. Imagine que você tem uma tabela chamada “usuarios” onde eu tenho os seguintes campos ‘nome,sobrenome,email,idade,estado‘ e precisamos selecionar os usuarios por uma certa idade no qual nos é passada via $_POST['idade'].

 

... Veja mais aqui

[Tiago Souza Ribeiro 8]

Só uma pergunta (qualquer um que quiser responder, fique a vontade :D):

Quais vantagens um usuário do MySQL apenas teria em usar PDO ao invés de MySQLi? Pelo que vi em vários lugares, a grande vantagem do PDO é o suporte a vários sistemas de banco de dados apenas, e até perde para o MySQLi em velocidade.

Alguém opina? :D

[Guilherme_90 33]

Só uma pergunta (qualquer um que quiser responder, fique a vontade :D):

Quais vantagens um usuário do MySQL apenas teria em usar PDO ao invés de MySQLi? Pelo que vi em vários lugares, a grande vantagem do PDO é o suporte a vários sistemas de banco de dados apenas, e até perde para o MySQLi em velocidade.

Alguém opina? :D

 

Onde está a fonte da informação que PDO perde pra MySQLi em performance? Não estou duvidando, porém a performance do PDO é muito boa, aliás, excelente, e feita em C.

[Tiago Souza Ribeiro 8]

Onde está a fonte da informação que PDO perde pra MySQLi em performance? Não estou duvidando, porém a performance do PDO é muito boa, aliás, excelente, e feita em C.

 

http://net.tutsplus.com/tutorials/php/pdo-vs-mysqli-which-should-you-use/

 

Aí nesse link fala lá na parte de Perfomance que MySQLi consegue uns 6,5% (pode ser muito em aplicações pesadas) de velocidade a mais que o PDO se usado prepared statements, e sem usar isso, é uns 2,5%.

[Guilherme_90 33]

Muito bacana cara, dei uma lida aqui. Fiquei até meio surpreso hehehe! Huuum, acho que vou criar um Statement no meu Mapper pra MySQLi.

[Bruno_Quaresma 3]

Bacana Thiago, eu não sabia dessa velocidade do MySQLi. Gosto de utilizar o PDO por ser mais fácil de se utilizar, porém... a implementação do MySQLi realmente faz a diferença na velocidade.

[Bruno Augusto 417]

A PDO é uma camada de abstração de banco de dados. E só.

 

A grosso modo ela abstrai a interface de utilização, o que significa que, por exemplo, a seguinte linha:

 

$conn = new PDO( /** ... */ );

$con -> query( /** ... */ );

Vai rodar em qualquer um dos drivers suportados pela PDO.

 

A "deficiência", entre aspas porque não é e nunca foi da alçada da PDO suportar, estaria no fato de que ela não abstrai a pseudo-linguagem SQL em si.

 

Um statement como:

 

SELECT COUNT(id) FROM tabela

Roda perfeitamente em MySQL e SQLite, dois bancos de dados que eu utilizo. Mas pode ser que ela não rode no Firebird ou no Informix, talvez pelo fato de um deles não reconhecer o COUNT() (caso hipotético, não testado).

 

Ela até tenta ampliar o suporte através de métodos específicos de cada driver, como por exemplo, PDO::sqliteCreateFunction que me permite executar um comando REGEXP, existente no MySQL, também no SQLite.

 

Porém tais métodos não estão presentes em todos os drivers visto que dependem fortemente do SGBD em questão. Vejam que esse caso citado só é possível porque o SQLite permite.

 

Nota: Esse link não se relaciona em nada com PHP, mas é através dessa possibilidade em C que a PDO permite tal expansibilidade.

 

Continuando... Se sua aplicação não tem qualquer possibilidade de usar outro SGBD, não existe motivo em se usar a PDO.

 

Se existe tal possibilidade, ainda assim deve-se pensar duas vezes antes de usá-la pelos motivos expostos acima (e outros mais).

 

E é bem aí que entram os Frameworks. Muitos deles complementam a excelência da PDO suprindo essa abstração do SQL combinando Fluent Interfaces em Query Object, separando a interface da renderização léxica das strings que formam o a query final.

[Vinicius Rangel 208]

Bruno primeiramente o que você postou ai me abriu a mente para umas coisas que nunca havia pensado antes mais eu fiquei com uma dúvida quanto ao seu argumento para não utilizar a biblioteca PDO.

 

Continuando... Se sua aplicação não tem qualquer possibilidade de usar outro SGBD, não existe motivo em se usar a PDO.

 

vejamos bem

 

Um SGBD - Sistema de Gerenciamento de Banco de Dados é uma coleção de programas que permitem ao usuário definir, construir e manipular Bases de Dados para as mais diversas finalidades.

 

então não seria "errado" você criar um projeto preso a uma estrutura? por menor que ele seja caso haja alguma alteração por parte do cliente em como ele quer esses dados sejam trabalhados a partir de agora podem gerar problema.

 

tentando ser mais claro

 

você desenvolve tudo em PDO e perde para o Mysqli no quesito tempo beleza, sei que para nós é igual F1 0.1 milessimo de segundos é realmente importante, veja bem que quando necessitar a alteração você já tem sua classe definida e começa apenas trabalhar na sua Controller se usa o MVC se não utiliza será algo parecido.

 

agora você trabalhou com Mysqli e ganha na performance necessário alguma alteração onde o usuário comece interagir, será que vale a pena esse tempo perdido na performance para se trabalhar com algo vamos se dizer estático(no sentido de endurecido a 1 propósito?)

 

essa dúvida me surgiu por base no seu comentário e ficaria grato a uma resposta

[Bruno_Quaresma 3]

Acharia melhor utilizar o PDO para que a aplicação seja portável em qualquer situação. Mas é como o Bruno Augusto disse, existem vários frameworks que complementam a funcinalidade do PDO, como por exemplo o DOCTRINE.

[Bruno Augusto 417]

Vinicius, quais os tipos de aplicações que jamais migrariam de banco de dados? Ou que a chance de isso acontecer seja bem pequena? Um dos que me vêm à são os hotsites, que depois de uns meses são excluídos.

 

Outro ponto. Antes de se começar a codificar um projeto, é feito um levantamento sobre o projeto e a empresa dona do mesmo. Dentre esses dados pode ser incluído uma projeção de crescimento tanto da empresa quanto do número de usuários em relação à divulgação da aplicação/site.

 

Só com isso o programador já consegue ter em mente se haverá a necessidade de migração ou não.

 

O MySQL é BEM parrudo, mesmo que quem conhece diga que o Postgree é melhor. Mas para determinadas coisas, SQLite e NoSQL são mais rápidos.

 

Cruzei com poucas diferenças entre MySQL e SQLite então usar a PDO "pura" para esses dois não seria um empecilho. Mas a PDO ainda não suporta NoSQL (mesmo que este não seja um SGBD propriamente dito).

 

E abstrair uma interface entre os diferentes drivers é quase que vital.

[Vinicius Rangel 208]

:clap:

 

entendido, obrigado

[Gabriel Heming 766]

será que vale a pena esse tempo perdido na performance para se trabalhar com algo vamos se dizer estático

Isso, é uma tremenda briga entre DBAs e desenvolvedores. Mas, brigam por que?

 

De fato, a atual tendência, é a independência dos SGBDs, visto o fato da maioria dos frameworks possuírem abstrações para a criação do SQL. Não preciso nem citar os mesmos nomes já citados.

 

Mas ai vem o fato da performance. Aqui, vocês citaram só, e somente só, a performance da MySQLi sobre PDO. E esqueceram-se do principal, os recursos que o SGBD oferece (indexes, triggers, stored procedures, functions, hierarquia, herença).

 

Por exemplo. MySQL não possui suporte a herança, PostgreSQL possui. Se desenvolverem só, e somente só, para postgre, vão poder usufruir de todos os recursos que o SGBD dispõe. 10% dos desenvolvedores utilizaram ou sabem o que é herança no SGBD.

 

O caso de triggers, diminui e muito inconsistências geradas por falha do PHP na interação com o banco de dados. Evita requisições desnecessárias e, ainda por cima, tem todo o suporte de transactions que só um SGBD possui em "background". Tente criar um sistema de transactions em nível de software, e verá a dor de cabeça.

 

Mas ai, vem o pessoal e diz: "Quer velocidade e performance? Utilize SGBD OO/NoSQL!"

 

Se fosse só, e somente só, isso, não existira o movimento MoreSQL. Ainda mais com apoio do Tatiyants. Apesar de ser mais sobre humor, que realidade, isso existe.

 

E no final, ficamos sem respostas, é uma briga antiga. Em certos pontos eu concordo, em outros eu discordo. Foi-se o tempo que um programador necessitava saber escovar bits para melhorar a performance de um sistema.

[Vinicius Rangel 208]

eu comecei estudando Mysql e Mysqli mais depois que descobrir o PDO passei a utilizar apenas ele por alguns motivos e agora que estão levantando alguns pontos gostaria de saber se há algumas outras possibilidades.

[Gabriel Heming 766]

Depende sua funcionalidade.

 

Por exemplo. Eu utilizo PDO para acesso ao MsSQL. Existem 3 drivers para isso: ODBC; DBLIB; SQLSRV.

 

Agora aos fatos:

 

- DBLIB. Somente para servidores windows. Extremamente rápida e nativa do PHP < 5.3. Foi descontinuada desde à partir do PHP 5.3 por não dar suporte a Linux.

- SQLSRV. Funciona tanto em Linux como Windows. Extremamente complicado de instalar. Existe uma versão para cada compilador e uma versão para cada versão do MsSQL (logo compilador X MsSQL = ∞ ).

- OBDC. Fácil de instalar. Suporte a MsSQL, DB2 e mais um que não me lembro, oracle eu acho. Um tanto chato de acessar o MsSQL dependendo da versão. Extramente lenta, a diferença de consulta da ODBC para qualquer um dos outros drivers é de segundos, em consulta simples.

 

Com todos esses fatos, chega a ser muito mais rápido, fácil e prático, ficar no velho mssql_connect().

 

Antes de escolher somente um, é bem interessante conhecer as "peculiaridades" de todos os existentes.

Atualmente, utilizo o ODBC, pois não houve "Cristo" de configurar acesso remoto do SQLSRV. Mesmo sendo a mesma versão de PHP e compiladores, há alguma incompatibilidade no acesso remoto, e a SQLSRV somente funciona no ambiente de produção e não no desenvolvimento. Acredito que é devido ao acesso remoto ao SGBD.

 

Então, tive de realizar testes em desenvolvimento X produção. Em desenvolvimento, terei de desenvolver com ODBC, e na produção, somente alterarei o driver para SQLSRV e rodará sem problemas (testado e aprovado... ufa).

[Vinicius Rangel 208]

como disseram cada um pode ganhar em uma coisa mais você tem que por em check o que é melhor para o sistema.

 

Performance x Segurança

 

 

parece que se falando de banco de dados essas duas coisas se desencontram pois o PDO tem uma excelente biblioteca na parte de segurança e me parece que o Mysqli agora ganha em performance.

 

agora respondam pra vocês mesmo, querem o sistema rápido ou seguro?

 

utilizar o bom e velho mysql_connect() será que vale o ganho na performance tanto assim?

 

ou será que vale ter tanta segurança e não abrir mão de um pouco que seja para melhoria do sistema.

[Gabriel Heming 766]

Na verdade, através de prepared statement, a PDO e MySQLi são mais rápidos que mysql_connect.

 

No caso das prepared statement, ela segue uma orgem:

1º - Cria-se o statement;

2º - Insere-se os valores (bindValue(), bindParam(), execute());

3º - Executa a query.

 

Com esses 3 passos, um de cada vez, o banco de dados está ciente do que vai ser pesquisado, e possui "tempo" de "trabalhar" os dados antes da consulta propriamente dita. Isso torna a consulta de forma muito mais rápida.

[Bruno Augusto 417]

E mais, com a PDO pelo menos, essas três etapas pode ser reduzidas para apenas duas se levar em conta que o binding pode ser substituído por um simples array diretamente no execute().

 

Quanto a usar mysql_*, esquece, ela será descontinuada logo.

[Gabriel Heming 766]

essas três etapas pode ser reduzidas para apenas duas

Sim e não.

 

Em linhas de código sim. Mas as 3 etapas continuarão existindo. Quando me referi a etapas, não me referia a código e sim a etapas que a query passava. Mesmo passando os parâmetros através do execute(), internamente, o bind é realizado. Após, é executada a query.

[Bruno Augusto 417]

Sei não, hein.

 

Porque quando se passa via execute(), se usando named placeholders devem haver índices associativos e quando não, utilizando question mark placeholders, índices numéricos comuns.

 

Isso me leva a crer que é tudo uma questão posicional. De fato, é feito um tipo de bind, mas não o mesmo tipo bind feito pelas funções acima.

 

Afinal se existem três métodos diferentes, estes existem para três situações distintas.

 

Sei lá, pode ser implicância minha... :P

 

Alguém se aventura a vasculhar o source da PDo, (se disponível) para sanara essa curiosidade?

[Gabriel Heming 766]

É bem verdade que existem 3 métodos diferentes. Os métodos bindValue e bindParam justificam suas existências.

 

- bindValue somente para valores estáticos;

- bindParam somente para valores passados por referência;

 

Entretanto, não há especificação nenhuma do que é utilizado em execute(). Exceto pelo fato de todos os dados serem tratados como PDO::PARAM_STR.

 

Logicamente, como é impossível haver alterações de variáveis (graças a não existência de treads) entre a referência dos parâmetros, através do execute, e a execução da query, se torna explícito que não é utilizado bindParam.

 

 

Edit---------------

Olhei o código fonte, e averiguei que as 3 funções usufruem do método really_register_bound_param. Até achei engraçado o seu nome. As diferenças:

 

- bindValue() executa diretamente essa função; (https://github.com/php/php-src/blob/master/ext/pdo/pdo_stmt.c line 1664)

- execute() executa diretamente essa função em uma iteração nos parâmetros; (https://github.com/php/php-src/blob/master/ext/pdo/pdo_stmt.c line 1647)

- bindParam() executa indiretamente essa função através da função register_bound_param(). (https://github.com/php/php-src/blob/master/ext/pdo/pdo_stmt.c line 480)

 

Não entendo muito de C, mas foi isso que pude averiguar.