Actualizar reglas de integridad

[lumines88]

Hola,

quiero cambiar una regla de integridad en una base de datos en un servidor ajeno. Tengo:

Código MySQL:

ALTER TABLE `usuarios`
  ADD CONSTRAINT `usuarios_ibfk_1` FOREIGN KEY (`idusuario`) REFERENCES `historial` (`idhistorial`) ON DELETE CASCADE ON UPDATE CASCADE;
 

Y quiero cambiarlo por:

Código MySQL:

ALTER TABLE `historial`
  ADD CONSTRAINT `historial_ibfk_1` FOREIGN KEY (`idhistorial`) REFERENCES `usuarios` (`idusuario`) ON DELETE NO ACTION ON UPDATE NO ACTION;
 

Pero, ¿cómo lo actualizo?

¡Gracias!

[gnzsoloyo]

Francamente no entiendo tu duda.
Si tienes que ejecutar cambiar una FK de una tabla, simplemente usas un ALTER TABLE para borrarla y otro para crear la nueva... Es ejecutar dos sentencias de SQL.
¿En qué consiste exactamente la duda?

[lumines88]

Pues es exactamente... ¿cómo lo hago? Porque casi toda la información que encuentro sobre alter table es para modificar campos y demás...
Por ejemplo, hago:

ALTER TABLE usuarios DROP CONSTRAINT usuarios_ibfk_1;

y me da error:

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 'CONSTRAINT usuarios_ibfk_1' at line 1

[gnzsoloyo]

Porque CONSTRAINT abarca varias cosas, claves primarias, claves foráneas, índices, por lo cual cuando le dices DROP CONSTRAINT no le estás diciendo nada claro, entonces.
El hecho de acompañarlo con el nombre de la constraint tampoco es suficiente indicativo, porque el nombre es personalizable y por tanto puede abarcar varias cosas distintas. En tu caso lo que es es una FOREIGN KEY.
Mira: 13.1.2. Sintaxis de ALTER TABLE.
Si te fijas con cuidado, en la 14ª opción dice precisamente DROP FOREIGN KEY fk_symbol donde fk_symbol es la denominación del indice para la FK que deseas borrar.
En otras palabras, lo que necesitas poner es:

Código MySQL:

ALTER TABLE usuarios DROP FOREIGN KEY usuarios_ibfk_1;
 

y luego

Código MySQL:

ALTER TABLE `historial`
  ADD CONSTRAINT `historial_ibfk_1` FOREIGN KEY (`idhistorial`) REFERENCES `usuarios` (`idusuario`) ON DELETE NO ACTION ON UPDATE NO ACTION;
 

Todas estas cosas son mucho más claras si las buscas en el manual de referencia. Lo demás importa muy poco.

[lumines88]

Tienes razón con el manual. Suelo mirar la documentación de Java pero en otros lenguajes ni se me ocurre ^^U

Pues me dan error las dos líneas...

Código MySQL:

ERROR 1025 (HY000): Error on rename of './db/usuarios' to './db/#sql2-6619-c511' (errno: 152)
 

Seguiré mirando a ver =/

[gnzsoloyo]

Eso ya es un error más fino... El error 1025 significa que se produjo un error al renombrar una tabla o archivo. Normalmente ocurre cuando MySQL crea archivos temporales en un ALTER TABLE, lo que normalmente significa que la sentencia falló por alguna razón.
El consejo más simple sería que probaras revisar si la FK fue bien borrada antes de proceder a crear la nueva. Es posible que alguna restricción adicional haya fallado, por ejemplo, que los tipos de columna de la PK de origen y de la FK destino no sean exactamente iguales.
Postea el CREATE TABLE de cada una y veamos si ese es el problema.

[lumines88]

Son estas tablas:

Código MySQL:

CREATE TABLE IF NOT EXISTS `historial` (
  `idhistorial` int(11) NOT NULL AUTO_INCREMENT,
  `idusuario` int(11) NOT NULL,
  `galeria` char(30) NOT NULL,
  `obra` char(40) NOT NULL,
  `precio` float NOT NULL,
  `metodo_pago` char(15) NOT NULL,
  `compraventa` varchar(20) NOT NULL,
  `idcreador` int(11) NOT NULL,
  `fecha` date NOT NULL,
  PRIMARY KEY (`idhistorial`)
) ENGINE=InnoDB  DEFAULT CHARSET=latin1 AUTO_INCREMENT=27 ;
 
CREATE TABLE IF NOT EXISTS `usuarios` (
  `idusuario` int(11) NOT NULL AUTO_INCREMENT,
  `nombre` char(25) NOT NULL,
  `apellidos` char(50) NOT NULL,
  `rol` char(15) NOT NULL,
  `password` varchar(40) NOT NULL,
  `provincia` char(50) NOT NULL,
  `ciudad` char(50) NOT NULL,
  `cp` int(11) NOT NULL,
  `direccion` char(100) NOT NULL,
  `email` char(40) NOT NULL,
  `movil` int(11) NOT NULL,
  `tarjeta` int(11) NOT NULL,
  `cambio` char(15) NOT NULL,
  PRIMARY KEY (`idusuario`)
) ENGINE=InnoDB  DEFAULT CHARSET=latin1 AUTO_INCREMENT=8 ;
 

Y las restricciones con las que tienen que ver:

Código MySQL:

ALTER TABLE `galerias`
  ADD CONSTRAINT `galerias_ibfk_2` FOREIGN KEY (`usuario_id`) REFERENCES `usuarios` (`idusuario`) ON DELETE CASCADE ON UPDATE CASCADE;
 
ALTER TABLE `usuarios`
  ADD CONSTRAINT `usuarios_ibfk_1` FOREIGN KEY (`idusuario`) REFERENCES `historial` (`idhistorial`) ON DELETE CASCADE ON UPDATE CASCADE;
 

Siendo la última la que quiero cambiar.

No creo que tenga nada que ver que en la tabla usuarios añadiera un campo a posteriori... más que nada porque está ya en las órdenes. Pero por si acaso...

[gnzsoloyo]

Dos detalles:
1) La FK que quieres definir no tiene sentido. Estás poniendo en Usuarios, que debería ser tabla base, una FK que apunta a la PK de Historial, cuando Historial debería ser la que tenga como FK el IdUsuario. En otras palabras, el historial es de un usuario, el usuario no le pertenece al historial. ¿Se entiende?
2) Cuando haces modificaciones de este nivel en tablas que ya contienen datos tienes que asegurarte que los datos que ya existen cumplan con las restricciones que quieres poner. En tu caso ambas tablas contienen datos, por lo que habría que verificar eso.
Fuera de eso, los datos parecen ser del mismo tipo, por lo que ese no sería el origen del error. Me presenta dudas el tema de los datos ya cargados. He visto este problema en esos casos muchas veces.
Verifica los datos o vacía las tablas.

Tip final: Un autoincrement sólo produce positivos, por lo que si pones INT como tipo de dato estás desaprovechando la mitad del rango de represnetaciones que se desperdicia por estar asignado a negativos. Los autoincrementales deben ser INT UNSIGNED.

[lumines88]

Hola,

he truncado todas las tablas en local y me ha funcionado, pero cuando me he conectado al servidor, me ha salido el mismo error.

Sí, sé que no tiene sentido la relación, pero... era de la única forma que no se me quejaba phpmyadmin :S

Me apunto lo de unsigned.

¡Gracias!

[gnzsoloyo]

Sí, sé que no tiene sentido la relación, pero... era de la única forma que no se me quejaba phpmyadmin :S

Explicame esto, porque no sé a qué te refieres.
Por otro lado, ten en cuenta que una relación no se pone porque sí. Esa relación de dependencia implica que antes de crear un usuario, deberás crear un registro en historial... ¿Le encuentras lógica?
Si PhpMyadmin se "quejaba", en todo caso es porque hay algún otro error de diseño subyacente.

pero cuando me he conectado al servidor, me ha salido el mismo error.

Si en el servidor tienes una copia de la que tenías en local, es lógico que pase, porque el servidor tiene sus propios datos, en ese caso. Y a menos que trunques las tablas del servidor la única solución será verificar la consistencia de los datos en el servidor respecto de la restricción que deseas poner.
El tema es que si el servidor está en producción (en trabajo), la tarea requerirá detener si o sí en algún momento la base para hacer la corrección.

[lumines88]

Pues me refiero a que o no me dejaba crear la relación, o no se solucionaba el problema.

No, no le veo la lógica. Es verdad. Buscaré a ver alguna otra relación que funcione.


Ya, pero he truncado los datos en el servidor también, así que sí que no debería haber tenido ningún problema...

[gnzsoloyo]

¿Cómo era la consulta con la que creabas esa relación?
¿Así?:

Código MySQL:

ALTER TABLE `historial`
      ADD CONSTRAINT `historial_ibfk_1` 
      FOREIGN KEY (`idhistorial`) 
      REFERENCES `usuarios` (`idusuario`) 
      ON DELETE NO ACTION ON UPDATE NO ACTION;
 

Porque en realidad, según tu tabla, debería ser así:

Código MySQL:

ALTER TABLE `historial`
      ADD CONSTRAINT `historial_ibfk_1` 
      FOREIGN KEY (`idusuario`) 
      REFERENCES `usuarios` (`idusuario`) 
      ON DELETE NO ACTION ON UPDATE NO ACTION;
 

O sea, el campo idusuario de la tabla historial es una FK de la tabla usuarios.

[lumines88]

Pues sí, está mal... qué desastre.

Aún cambiándolo no la crea. Aunque claro, tengo que eliminar la otra antes...