Hoy desde la playa y bajo un imperoso sol os dejo un enlace donde nos invitan a someter a rigurosa dieta a nuestras bases de datos, es obvio y todos ya lo sabemos, pero el autor del post original lo ha medido y cuantificado, dale!  http://af-design.com/blog/2009/02/24/a-smaller-database-is-a-faster-database/

Me ha costado un poco más configurar phpMyAdmin para que corra con Nginx, que aprender a pronunciar el nombre de este buen servidor web sin guiñar ninguno de ambos ojos… digo bueno porque literalmente se repasa al venerable Apache, que por viejo está gordo como ninguno, eso sí, sabe de todo, pero pero es un glotón de recursos.

En el panorama actual existen diversas soluciones libres para establecer un buen servidor web, desde el aclamado Cheroke, un web server creado por el español Álvaro López Ortega y que prometo probar en un futuro, al famoso Lighttpd, otro cuyo nombre se las tra, y el nginx, donde me gustaría ver a Paco León, genio y artista, pronunciar semejante nombre como cuando lo intentó con Shreek y cuyo testigo queda en YouTube.

Hemos escogido Nginx pues las comparativas que hemos leído sobre él destroza a cualquier otros servidor web en cuanto al escaso consumo de recursos que precisa, estableciendo un ratio de 1:10 contra por ejemplo Apache, es un servidor ligero, muy ligero y cuya configuración no es en exceso difícil para alguien que se maneje un poco con la línea de comando de Linux, ahora bien, el problema ha llegado al intentar configurar phpMyAdmin bajo él, de todos, todos, los tutoriales que hemos visitado, ninguno ha funcionando, hasta que al final hemos copiado el directorio de la carpeta /usr/share/phpmyadmin a dentro del propio directorio del webserver /var/www una solución temporal, pero que nos va a servir para comprobar el rendimiento del conjunto nginx+php+mysql+phpmyadmin como futuro para nuestros servidores de producción donde correr nuestras aplicaciones web.

Como apunte os diremos que algunas de las mayores webs del mundo, aquellas que tienen un tráfico brutal, funcionan bajo nginx, por ejemplo YouTube, y hace poco también migró de Apache a nginx la española “meneame”.

Ahora, repite conmigo: enllins, einnllinss, enellinks, enjinks y quédate con la que quieras pero quédate.

Menudo bugazo de MySQLos hemos encontrado hoy! Este bug porque sí, porque lo es ya que tiene toda la pinta de ser un bicho nos ha traído de cabeza durante dos días. Si ya pensaba yo que esto de que Oracle salga de compras no nos iba a traer nada pero nada bueno, en fin webmaster of the universe os ponemos en antecedentes:

Estamos ultimando la v.3.9 del sistema de tiendas online ecOOmmerce.com en ella hemos incorporado una función que realiza las actualizador de precios y de stock semiautomatizado donde el cliente en base a un fichero bajo formato .csv (parecido al excel, realmente es un txt con campos separados por un signo) puede desde el backoffice de la aplicación actualizar los precios de una tacada.

El servidor web alojado en Hispalab corre Linux con Mysql versión 5.0.90 instalada. Nosotros disponemos acceso al Cpanel para administrar, si bien no podemos acceder a consola por SSH ni a través de Cpanel.

Intentamos hacer un típico LOAD DATA LOCAL INFILE para cargar datos de un fichero .csv en una tabla temporal de la base de datos que posteriormente será analizada por nuestra nueva función y actualizará los precios.

La sentencia es la típica, reportada en cientos y cientos de foros de desarrollo tanto en español como en lengua sajona:

LOAD DATA LOCAL INFILE ”/home/dominios/test/public_html/tmp/tarifatest.csv” INTO TABLE table01 FIELDS TERMINATED BY “;” LINES TERMINATED BY “\n”

Y desde la aplicación no recibimos error alguno, para acotar el tema vamos al Phpmyadmin a través de Cpanel y copypasteamos el comando, automáticamente nos escupe el siguiente error:

#1148 – The used command is not allowed with this MySQL version

Repasamos la sentencia de SQL mil quinientas veces y es entonces cuando el ingeniero de sistemas de Hispalab nos dice que no utilicemos el “LOCAL”. Nos documentamos y si, una vez el archivo está en servidor no hace falta utilizar el argumento “LOCAL” ahora bien, al modificar esta función nos encontramos con otro nuevo error:

#1045 – Access denied for user ’wwwtest’@'localhost’ (using password: YES)

Así que comenzamos primero desde PHP y luego desde FTP (no tenemos acceso a consola) ha realizar todo tipo de CHMODS y CHOWN para cambiar los permisos y propietarios de el archivo y la carpeta subida. No conseguimos nada más que perder el tiempo.

Desolados reportamos a Hispalab y al final y tras casi dos días de darnos cabezazos contra el teclado alguien vio la luz en Hispalab, ese LOCAL, ese LOCAL, lo probó en minúsculas “local” y… como bien dijo el “zasss…. todo funcionó”.

Impresionante, ni en la propia documentación de MySQL figura ni una sóla vez en minúsculas, puedes verlo en:

http://dev.mysql.com/doc/refman/5.1/en/load-data.html

En fin, hay queda este post por si alguna vez oss encontráis con semejante problema.