Recientemente, me vi en la necesidad de hacer una migración de MSAccess a MySQL (en realidad la hice a MariaDB), y cuando estuve normalizando la base de datos y agregando las relaciones respectivas me encontré con el famoso y a la vez desconocido mensaje:

Error 1005: Can’t create table ‘NombreTabla’ (errno. 121)

Este error se produce en dos situaciones (básicamente):

1. La tabla tiene un error interno, ya sea por indexación o similares, en donde la solución es simplemente reconstruir la tabla.
2. Al agregar una relación, no hay integridad referencial, caso en el cual, generalmente, yo asigno como valor por defecto el valor NULL al campo relacional.

Pero este no fue mi caso en esta ocasión. Todo lucía bien, reconstruí la tabla, verifiqué la integridad referencial y todo lucía perfecto. Excepto porque no podía agregar campos relacionales a varias de las tablas. Le pregunté a San Google y otros santos, sin éxito, así que decidí ponerme a la tarea de probar alternativas hasta encontrar el problema.


Para hacer la historia corta, resultó ser un pequeñísimo detalle que había pasado por alto. Recuerdo cuando aprendí Oracle en donde mi instructor me decía que los nombres de los CONSTRAINTs en Oracle son únicos y no pueden duplicarse, así que probé suerte y funcionó.


La solución es simple y la voy a ilustrar con una consulta, en donde existe una tabla Customer (me está gustando este nombre para los ejemplos) y debe hacer referencia a la tabla City por el campo cityid. Así que la consulta (según mis propios estándares de nombres y normalización quedaría algo así:

ALTER TABLE `Customer`
ADD CONSTRAINT `Customer_Cityid_fk`
FOREIGN KEY (`cityid` )
REFERENCES `City` (`id` )
ON DELETE RESTRICT
ON UPDATE CASCADE
;

La parte importante es “ADD CONSTRAINT `Customer_Cityid_fk`”. En fin, problema resuelto.

¿Alguna vez se le presentó algún error en MySQL/MariaDB que no tuviera explicación aparente?

Al día de hoy, el equipo de desarrollo de PostgreSQL realizó la última actualización de seguridad y corrección de errores a las versiones 7.4 y 8.0 del motor de base de datos y anunció que: “recomienda que los usuarios que todavía usan estas versiones en producción empiecen a planear actualizarse a la última versión inmediatamente”. (Fuente: PostgreSQL)

Personalmente me agrada bastante la idea pues hay herramientas, funciones y características en general que no existen en esas versiones y cada vez se hace más difícil hacer que un sistema se totalmente compatible con esas versiones de PostgreSQL, además, de esa manera se puede concentrar el trabajo en potenciar la versión 9.0 que por cierto es bastante prometedora. En mi caso estoy usando la versión alpha.

¿Qué opinan de la determinación del equipo de de desarrollo de no mantener más esas versiones?

Acepto que este no es un problema al que me enfrento todos los días y menos en este gestor de bases de datos. En los demás motores como Oracle y PostgreSQL no había tenido ese problema (hasta donde recuerdo). Pero hoy tuve la necesidad de eliminar algunos registros duplicados de una tabla de un cliente (él deseaba eliminar los registros duplicados de sus clientes).

Al solicitarme el trabajo procedí a usar una sentencia del estilo:

DELETE FROM Customer cc
WHERE cc.email IN (
SELECT c.email
FROM Customer c
...
HAVING count(c.email)>1
)

Sencillo, práctico e intuitivo, ¿no? Le digo al gestor de base de datos que elimine los registros de la tabla Customer que tienen más de una incidencia. Pero tal fue mi sorpresa que me encontré con el siguiente error:

Error: #1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'cc WHERE cc.email IN (SELECT c.email FROM Customer c' at line 1

Y en algún momento me encontré con un error como:

#1093 - You can't specify target table 'Customer' for update in FROM clause

Así que entonces empezó la labor de investigación (¿o quise decir el dolor de cabeza?). Luego de visitar una buena cantidad de páginas web relacionadas, la documentación de MySQL (que por cierto no menciona qué hacer en esos casos), encontré que situaciones como la que necesitaba se resuelve con una eliminación relacional (algo que creo solo existe en MySQL/MariaDB). Para mi caso la consulta quedó así:

DELETE FROM Customer
USING Customer, Customer as c
WHERE (NOT Customer.id=c.id)
AND (Customer.email=c.email)

¿Alguna duda? Sé que no es tan intuitiva como la primera sentencia, pero luego de revisarla detenidamente tuvo sentido para mí. Básicamente lo que hace la sentencia es decir que elimine de Customer haciendo una relación con Customer (con la misma tabla) en donde el ID sea diferente y el email se igual.

La anterior sentencia tiene un pequeño y grave problema: Borra todos los registros que se enuentran duplicados, conservando los que no lo están. Averiguando en diferentes sitios encontré la solución ideal en CommentÇaMarche:

ALTER IGNORE TABLE  TabTest ADD UNIQUE INDEX(x,y);

En donde los campos del índice son los que deseamos verificar que sean únicos, no repetidos, borrando del segundo en adelante.

Espero ahorrarles la búsqueda y desde luego dolores de cabeza.

El primer lanzamiento oficial de la versión beta del motor de base de datos PostgreSQL versión 9.0 ya está disponible. La versión 9.0 es la priemra versión de PostgreSQL que incluye las librerías y los binarios necesarios para para replicación de bases de datos en tiempo con consultas escalables o scale-out, y que expandirá la adopción de PostgreSQL por parte de nuevos usuarios y para nuevos tipos de aplicaciones. Vale la pena probarla.

La noticia en PostgreSQL.org.