Interneteando

Para realizar las pruebas se ha utilizado una tabla en formato MyISAM con 1753184 registros rellenados con datos aleatorios.

Ambos almacenan datos de tipo cadena, la longitud de que ocupa cada caracter suele ser de 1 byte, exceptuando las cadenas “unicode” que pueden llegar a ocupar hasta 3 bytes por caracter. El tamañó máximo para este tipo de campos es de 256 bytes. En los ejemplos me referiré siempre a letras en vez de bytes para hacer más facil su comprensión.

CHAR: Es un tipo de longitud fija, esto quiere decir que el espacio necesario para su almacenamiento es el mismo para una palabra de 5 letras que para una frase de 20.

VARCHAR: Es un campo de longitud dinámica, es decir una palabra de 5 letras, ocupará el espacio de 5 letras más un caracter de fin de cadena.

Casos de uso.

SELECT campo2 from tabla WHERE campo2 = ‘cadena’;
campo2 => VARCHAR(200) => 1,82 segundos sin indexar => 0,00 indexado
campo3 => CHAR(200) => 1,77 segundos sin indexar => 0,00 indexado

SELECT campo2 from tablal where campo2 like ‘%dena%’;
campo2 => VARCHAR(200) => 3,86 segundos sin indexar => 1,75 indexado
campo3 => CHAR(200) => 1,84 segundos sin indexar => 2,19 indexado

Después de estas pruebas, podemos concluir que CHAR se comporta mejor que VARCHAR en campos no indexados, y que VARCHAR es la mejor opción para campos que si soporten indexación.

A la hora de devolver gran número de resultados VARCHAR también se muestra superior sobre CHAR. Un SELECT con 1000000 de resultados tardó en devolver una columna de tipo char 1,24 segundos. La misma columna en formato VARCHAR tan solo tardó 1,06 segundos.

Hoy leía en el blog de Pichongol un interesante artículo sobre la cache que incorpora MySQL y el uso de Memcached para optimizar la carga de sitios web con gran carga de trabajo, pero creo que no está del todo acertado en algunos aspectos.

En su análisis sobre Sistemas intensivos en lecturas vs. Sistemas intensivos en escrituras, pasa por alto un detalle de gran importancia. Las páginas web (que es lo que nos ocupa), son sistemas en los que se acometen muchas lecturas y pocas escrituras por lo que en el 99% de los casos el uso del query cache será beneficioso. Además siempre se pueden utilizar tablas auxiliares para cierto tipo de operaciones de escritura masiva (contadores,estadísticas,sesiones, etc) y utilizar las extensiones de MySQL INSERT DELAYED y INSERT DELAYED … ON DUPLICATE UPDATE para acometer las actualizaciones en estas tablas sin influir en el tiempo de ejecución del script.

Sobre el uso de Memcached, también se pasa por alto un detalle importante, Memcached puede hacer persistir objetos en memoria para distintas máquinas a lo largo de una red y de esta forma varias máquinas se aprovechan del calculo realizado por una. Si hablamos de instalaciones de un solo servidor, el coste de las funciones serialize y unserialize reducen bastante las ventajas de utilizar Memcached.

Por mi experiencia, Memcached es especialmente productivo para entornos de balanceo de carga y funciona especialmente bien en combinación con Lighttpd+FastCGI.

Llevo utilizando PDT desde sus primeras versiones, y según me iba acomodando, también cambiaba mi forma de programar en PHP.

Antes utilizaba BBedit y ahora utilizo PDT.
Antes utilizaba programación modular y ahora programación orientada a objetos.

Sobre si es mejor la programación modular o la programación orientada a objetos, hay mucha gente más lista que yo ya ha opinado sobre ello así que lo pasaremos por alto.

Ahora bien, si al final decides que tu proyecto en concreto vas a utilizar objetos, el PDT ofrece ciertas ayudas de las que no dispone ningún otro editor de texto que yo conozca. En esta comparativa entre PDT y Zend Studio for Eclipse hay un montón de características que hacen del PDT, la mejor herramienta para la programación orientada a objetos en PHP a falta de probar a fondo el Zend Studio.

Esta transición, me ha llevado a producir un código mucho más entendible, extensible y fácil de mantener, a costa de hacer unos programas con más lentos.

De momento estoy contento con los resultados obtenidos, puesto qué tiempo de procesador me sobra mientras qué mi tiempo de programación escasea cada vez más.