Tag mysql (Página 10) - Userlinux.net

Un pequeño error de diseño se puede pagar con algo así:

SELECT slug, id 
FROM posts 
WHERE id NOT IN
(
	SELECT p.id FROM (
		SELECT DISTINCT slug, id
		FROM posts
		GROUP BY slug
	) AS p
);

El bug surge por no haber puesto un campo único como tal. Supongamos que el campo slug¹⁾ de cada noticia no es único e introducimos dos slugs iguales: tenemos un problema.

Ivan es el hijo de Andrii Nikitin (Ingeniero de soporte en MySQL AB), y como en algunos Spam fraudulentos y redactados en Spanglish que recibimos a diario, necesita un trasplante de médula ósea. Sólo que esta vez ni es Spam, ni es un fraude, ni tiene gracia.

La nota de Andrii la cito traducida a continuación, y está extractada de la propia web de MySQL AB, donde están dando difusión a esta noticia:

Cuando pretendes programar una especie de buscador para integrar en una web y te pones a leer las múltiples y distintas formas de hacerlo te das cuenta de que LIKE no es la solución. Y menos aún habiendo funciones Full Text Search.

El supuesto es sencillo, un par de campos determinantes en la búsqueda para que los resultados sean adecuados. Por ejemplo los campos título y contenido de una tabla noticias. El típico:

Si un post pudiera tener asociadas N categorías y a su vez M comentarios sería un super-post. Y si todo ello pretende estar normalizado en una base de datos relacional, con sus tablas independientes, sus keys y sus índices... ¡a quién no le gustaría ser post!.

El problema viene cuando un programador pretende sacar en la misma consulta -por aquello de no ahogar más si cabe el cuello de botella- los datos principales del post y el número de comentarios que tiene. Todo ello perteneciente a una categoría -category_id=9 en el ejemplo-. Pónganse los cinturones.

Paso obligado en la instalación de MySQL, poner una nueva contraseña al usuario root:

$ mysqladmin -u root password nuevo_password

Sin embargo si queremos hacerlo en una máquina donde hemos olvidado la contraseña root de MySQL pero tenemos acceso shell con este mismo usuario la cosa cambia:

# /etc/rc.d/init.d/mysql stop
# mysqld --skip-grant-tables &
 mysql
 use mysql;
 UPDATE user SET Password=PASSWORD('nuevo_password') WHERE User="root";
 flush privileges;
 exit
# /etc/rc.d/init.d/mysql stop
# /etc/rc.d/init.d/mysql start

Estoy migrando algún que otro Drupal -por desgracia- de hosting y siempre se generan molestas tiranteces -hablando bien- de configuración. Dejando a un lado las incompatibilidades de los módulos, lo más común suele venir dado por la codificación de la base de datos.

En este caso se trata de dumpear e importar en latin1, así que con paciencia y buena letra nos disponemos a acabar el trabajo en 3 minutos.

Es lo que tienen las actualizaciones, te enteras de detalles que en su día se pasaron por alto y, para que engañarnos, suele amargar. Hay pequeñas diferencias entre la última rama 5.1 de MySQL y las anteriores (5.0, 4.1, 4.0, 3.23) y una de las puñeteras radica en la forma de logueo.

Antes era sencillo, al menos en FreeBSD, poner a loguear un mysqld, con decírselo a nuestro gran amigo el rc.conf, el resto era pan comido:

# MySQL
mysql_enable="YES"
mysql_args="--log=/var/log/mysql/mysql.log --log-error=/var/log/mysql/mysql.err.log"

Ahora, además de indicarle las rutas donde queremos guardar los logs, debemos decirle que lo haga en un fichero (FILE), porque sino creerá que queremos hacerlo en una base de datos, he ahí la gran diferencia entre la última rama (actualmente) y sus hermanas pequeñas:

# MySQL
mysql_enable="YES"
mysql_args="--log-output=FILE --log=/var/log/mysql/mysql.log --log-error=/var/log/mysql/mysql.err.log"

Ya sabeis, al actualizar no os olvideis de indicar '--log-output=FILE' como argumento previo a los logs. Lo que tiene no estar a la última.

Hace un rato me ha dado por jugar con Apache2 en una máquina de pruebas. Intentando modificar ciertas páginas PHP he encontrado un problema de codificación de texto, tanto en acentos como en eñes salían caracteres raros, por lo que pensé si sería problema de la actualización de Apache. Así que haciendo una búsqueda en apache2.conf por 'charset' topé con lo siguiente:

En una red informática compuesta por más de un equipo es interesante habilitar algún servicio de transferencia de ficheros para compartir información entre ordenadores. Existen varios protocolos usables para dicha tarea (NFS, Samba, HTTP...) pero solamente uno se ha creado específicamente con este fin: FTP (file transfer protocol).

Generalmente cuando tratemos de poner a funcionar un servicio cliente/servidor, debemos hacer mayor hincapié en la parte del servidor y configurarla de forma adecuada al uso que se le pueda dar en un futuro. Al principio es probable que el número de usuarios sea pequeño y no merezca la pena configurar tasas de transferencia o quotas en disco, pero a medida que se ofrece un servicio, las exigencias van cambiando y se hacen cada vez más necesarias.