Optimizaciones

ADOdb nos permite realizar algunas optimizaciones que mejoran considerablemente la performance y minimizan la carga del servidor. Veremos algunas a continuación.

Consultas preparadas

Tal como comentamos anteriormente, algunos motores de bases de datos soportan consultas preparadas. Para estas existen metodos para trabajar con ellas desde ADOdb.

Prepare($sql)

Prepara (compila) una consulta SQL para ejecuciones repetitivas. Enlaza los parametros denotados por el signo de pregunta (?), excepto para oracle que usa el tradicional convención de :nombrevariable.

Regresa un array conteniendo el SQL original en el primer elemento, los demás elementos dependen del driver que estemos usando.

Prepare() no puede ser utilizado con métodos que sobreescriben la consulta, tales como SelectLimit (que agrega a la consulta la límitación de filas).

Veamos un ejemplo:

<?php

	$db = ADONewConnection('mysql');

	$connected = @$db->Connect(_db_host, _db_user, _db_pass, _db_name);

	if(!$connected)

		throw new Exception('No pudimos conectarnos a la BD...');

	$db->Execute("SET NAMES 'utf8'");

	$stmt = $db->Prepare('INSERT INTO tabla (col1, col2) VALUES (?,?)');

	for ($i=0; $i < $max; $i++) {

		$db->Execute($stmt, array((string) rand(), $i));

	}

?>

Se aconseja utilizar consultas preparadas con motores que lo soporten, ya que una de las ventajas de utilizar consultas preparadas es ganar performance. ADOdb emula consultas preparadas si el motor no lo soporta, lo cual no brinda la ventaja anteriormente mencionada.

Caché

La caché de ADOdb actúa sobre consultas independientes. Es decir, se pueden cachear consultas por un tiempo determinado, en disco u otro artificio para asi en ejecuciones posteriores de estas mismas consultas, con los mismos parámetros, se lean los resultados desde la caché evitando asi la necesidad de uso del servidor de bases de datos.

El uso de este tipo de caché debe ser antecedido por un estudio de performance, evaluando en que casos usar caché y en cuales continuar utilizando consultas vivas. Algunos factores que determinan esta desición radican en el uso de la cache, si se utilizan discos rigidos lentos, en la cantidad de consultas en determinado tiempo que se deben realizar, en el trafico de la red si el servidor web está en otra maquina de la red diferente a donde reside el servidor de la base de datos, etc.

En el caso de optar por la caché, disponemos de las siguientes variantes de los métodos antes mencionados, los cuales deciden cuando utilizar datos de la caché y cuando actualizar la misma con datos frescos de la base de datos.

La etapa de "setup" necesita mínimamente los siguiente:

global $ADODB_CACHE_DIR;

$ADODB_CACHE_DIR = 'directorio_cache_adodb';

$db->cacheSecs = 3600;

Setear el directorio donde almacenaremos los archivos de caché y el tiempo general de actualización medido en segundos. Este tiempo de actualización se aplica a todas las consultas que realicemos, excepto que especifiquemos este tiempo en los métodos de selección directamente.

Los métodos mas usuales para cachear son los siguientes:

CacheGetOne

CacheGetRow

CacheSelectLimit

CacheGetAssoc

Su uso es idéntico a los explicados en los ejemplos anteriores.

No olvidemos mencionar que ADOdb permite utilizar Memcached para optimizar aún más las opciones de caching.

Transacciones

Para los motores gestores de bases de datos que soporten los principios ACID, ADOdb nos presenta la posibilidad de utilizar transacciones de la siguiente manera.

StartTrans()

Inicia una transacción monitoreada.A medida que las sentencias SQL sean ejecutadas, ADOdb monitorea los posibles errores ocurridos, y si se detecta alguno, al invocar CompleteTrans(), se produce un rollback automático.

Para entender porque StartTrans() es mejor a BeginTrans() veamos formas de usar BeginTrans(). La siguiente es la manera erronea de usar transacciones:

<?php

$db->BeginTrans();

$db->Execute("update table1 set val=$val1 where id=$id");

$db->Execute("update table2 set val=$val2 where id=$id");

$db->CommitTrans();

?>

Porque no se realiza ningún chequeo de errores. Es posible actualizar table1 y que falle la actualización en table2. Esta es una mejor manera:

<?php

$db->BeginTrans();

$ok = $db->Execute("update table1 set val=$val1 where id=$id");

if ($ok) $ok = $db->Execute("update table2 set val=$val2 where id=$id");

if ($ok) $db->CommitTrans();

else $db->RollbackTrans();

?>

Otra manera es (desde ADOdb 2.0):

<?php

$db->BeginTrans();

$ok = $db->Execute("update table1 set val=$val1 where id=$id");

if ($ok) $ok = $db->Execute("update table2 set val=$val2 where id=$id");

$db->CommitTrans($ok);

?>

Como se puede ver es un dolor de cabeza monitorear todos los $ok.
StartTrans() es una mejora porque monitorea todos los errores SQL por usted.
Esto es particularmente util si se invocan funciones genericas (caja negra) donde consultas SQL pueden ejecutarse.
Además BeginTrans, CommitTrans y RollbackTrans llamadas dentro de un bloque StartTrans serán deshabilitadas, asi que si una función genérica hace un commit, este será ignorado.

CompleteTrans($autoComplete=true)

Completa una transacción iniciada con StartTrans(). Esta función monitorea errores SQL y hará un commit si no hay errores o un rollback si encuentra alguno.
Regresa true al hacer commit o falso al hacer rollback.
Si $autoComplete es true se comportará como fue explicado. Pero si $autoComplete es false, se forzará un rollback incluso si no ocurrieron errores SQL.

FailTrans()

Hace fallar una transacción iniciada con StartTrans(). El rollback solo ocurrirá al momento de invocar CompleteTrans().

HasFailedTrans()

Verifica cuando una transacción ha fallado. Regresa true si se detectó un error o si FailTrans() ha sido invocado. De otra manera retorna false.

BeginTrans()

Comienza una transacción. Deshabilita autoCommit. Regresa true si pudo comenzar una transacción. Algunas bases de datos regresarán false si no soportan transacciones. A cualquier transacción abierta se le hará un rollback cuando se cierre la conexión.

Note que StartTrans y CompleteTrans() son metodos superiores para manejar transacciones, a partir de ADOdb 3.40.

Detectando transacciones.

Desde ADOdb 2.50, es capaz de detectar cuando se está dentro de una transacción, verificando que $db->transCnt sea mayor a cero. Esta variable se incrementa cuando se invoca BeginTrans() y se decrementa cuando se invoca RollbackTrans() o CommitTrans().

CommitTrans($ok=true)

Termina exitosamente una transacción. Regresa true si pudo lograrlo. Si la base d edatos no soporta transacciones, regresará true dado que los datos siempre serán grabados.

Si se pasa el parámetro $ok=false, se hara un rollback.

RollbackTrans()

Termina la transacción haciendo rollback a todos los cambios. Regresa true si pudo lograrlo. Si la base de datos no soporta transacciones regresará false dado que nunca se podrá volver atras a los cambios.

SetTransactionMode($mode)

SetTransactionMode permite especificar el modo de transacción que se utilizará en las subsecuentes transacciones.
Si se están usando conexiones persistentes y se está usando mssql o mysql, se necesita resetear explicitamente el modo de transacción al inicio de cada petición de página. Esto es solo soportado por postgresql, mssql, mysql con InnoDB y oci8 actualmente. Veamos un ejemplo:

<?php

$db->SetTransactionMode("SERIALIZABLE");

$db->BeginTrans();

$db->Execute(...); $db->Execute(...);

$db->CommiTrans();



$db->SetTransactionMode(""); // Volvemos al default

$db->StartTrans();

$db->Execute(...); $db->Execute(...);

$db->CompleteTrans();

?>

Los valores soportados son:

    * READ UNCOMMITTED (Permite lecturas sucias [dirty reads], pero rápidas)

    * READ COMMITTED (Por defecto para postgres, mssql y oci8)

    * REPEATABLE READ (Por defecto para mysql)

    * SERIALIZABLE (La más lenta y más restrictiva)

Conclusión y enlaces de interés.

¿Porqué usar ADOdb en lugar de otras alternativas?

Hoy día la alternativa más fuerte es PDO (PHP Data Objects). Una capa de abstracción nativa muy bien lograda y documentada. Personalmente me es indistinto usar uno u otro, sin embargo PDO trabaja de una manera orientada a objetos más estricta y tiene un soporte para consultas preparadas muy potente.
Pear también trae por su lado un conjunto de clases y funciones para trabajar con bases de datos.

ADOdb años de uso y desarrollo que lo posicionan como una opción más que fiable a la hora de realizar desarrollo con bases de datos. Soporta una gran variedad de motores y es muy completa en métodos y extras, como pudo ser visto en el desarrollo del artículo. Si se lo utiliza correctamente es posible realizar migraciones entre diferentes motores sin tener que modificar ni una línea de código. Y eso, es mucho decir.

Enlaces

ADOdb
ADOdb en Wikipedia
Documentación - Ingles
Documentación - Español