Duda con truncate.

[RIVERMILLOS]

hola tengo dos tablas mas o menos asi

tabla_1
id
mensaje
imagen
id_fk_otratabla1
id_fk_otratabla2


tabla_2
id
idtabla_1
campo1
campo



estan relacionadas , pero cuando quiero hacerle truncate a la tabla_1 me dice esto

Cannot truncate a table referenced in a foreign key constraint


y tengo ON DELETE CASCADE pense que si borraba todo de tabla_1 se borraria todo de tabla2 no entiendo porque me sale esto?


saludos

[gnzsoloyo]

El problema es que tienes una interdependencia en alguna parte.
Si la FK de Tabla1 a Tabla2 tiene la clausula ON DELETE CASCADE, borrar Tabla2 eliminaría los registros vinculados en Tabla1. La pregunta es si hay alguna otra tabla que dependa de Tabla2, o si existe alguna tabla que dependa de la PK de Tabla1.
Ten en cuenta que los esquemas de integridad referencial funcionan como un todo integrado... No son cosas sencillas.

[papay0]

tienes que truncar primero la tabla hija y despues la padre o quitar las llaves foraneas

[RIVERMILLOS]

esta son las tablas que tengo y la tabla reglaspropiedades es la que no se deja hacer truncate.




Saludos

[gnzsoloyo]

No puedes borrar reglaspropiedades porque si te fijas las tablas reglasxrpiedades y preguntas dependen de ella.
Para que se pueda borrar directamente esa tabla, la definición de las tablas reglasxrpiedades y preguntas también deben tener la clausula ON DELETE CASCADE en sus FK.
A esto es a lo que me referia cuando dije que los esquemas de integridad referencial funcionan como un todo.

[RIVERMILLOS]

eso es lo que no entiendo porque las Fk de la tabla preguntas y reglasxpropiedades tiene on DELTE CASCADE , puede que esto sea ocacionado por eso?


saludos

[gnzsoloyo]

Bueno, entonces hagamos una comprobación:

Código MySQL:

SELECT DISTINCT
  K.REFERENCED_TABLE_SCHEMA,
  K.REFERENCED_TABLE_NAME
FROM
  information_schema.KEY_COLUMN_USAGE K INNER JOIN
  information_schema.TABLE_CONSTRAINTS T USING(TABLE_SCHEMA, TABLE_NAME)
WHERE
  T.CONSTRAINT_TYPE = 'FOREIGN KEY' AND
  T.TABLE_NAME = 'reglaspropiedades ';
 

Eso te debería devolver la lista de tablas donde hay FK apuntando a esa. Si no devuelve ninguna otra, entonces hay que verificar por los nombres de las otras (T.TABLE_NAME), para ver si hay alguna dependencia transitiva que no esté clara.

[RIVERMILLOS]

Mira esto fue lo que me retorno la consulta.

Código:

REFERENCED_TABLE_SCHEMA, REFERENCED_TABLE_NAME

'  ', '  '

'ortegayb_btc', 'accionesreglas'

'ortegayb_btc', 'titulos'

saludos

[gnzsoloyo]

Perdón creo que te puse al revés la idea:

Código MySQL:

SELECT DISTINCT
  K.TABLE_SCHEMA,
  K.TABLE_NAME
FROM
  information_schema.KEY_COLUMN_USAGE K INNER JOIN
  information_schema.TABLE_CONSTRAINTS T USING(TABLE_SCHEMA, TABLE_NAME)
WHERE
  T.CONSTRAINT_TYPE = 'FOREIGN KEY' AND
  K.REFERENCED_TABLE_NAME = 'reglaspropiedades ';
 

[gnzsoloyo]

Si eso devuelve sólo esas dos tablas, entonces hay que probar:

Código MySQL:

SELECT DISTINCT
  K.TABLE_SCHEMA,
  K.TABLE_NAME
FROM
  information_schema.KEY_COLUMN_USAGE K INNER JOIN
  information_schema.TABLE_CONSTRAINTS T USING(TABLE_SCHEMA, TABLE_NAME)
WHERE
  T.CONSTRAINT_TYPE = 'FOREIGN KEY' AND
  K.REFERENCED_TABLE_NAME = 'reglasxrpiedades';
 

Y además:

Código MySQL:

SELECT DISTINCT
  K.TABLE_SCHEMA,
  K.TABLE_NAME
FROM
  information_schema.KEY_COLUMN_USAGE K INNER JOIN
  information_schema.TABLE_CONSTRAINTS T USING(TABLE_SCHEMA, TABLE_NAME)
WHERE
  T.CONSTRAINT_TYPE = 'FOREIGN KEY' AND
  K.REFERENCED_TABLE_NAME = 'preguntas';
 

[RIVERMILLOS]

Las dos consultas no me retornan nada.. si deberia ser asi?


saludos

[gnzsoloyo]

¿Y la anterior (post Nro. 9)?

[RIVERMILLOS]

retorna esto


'ortegayb_btc', 'preguntas'
'ortegayb_btc', 'reglasxpropiedades'


saludos

[gnzsoloyo]

'ortegayb_btc', 'preguntas'
'ortegayb_btc', 'reglasxpropiedades'

Bien, efectivamente nos encontramos ante un misterio. Esas dos tabla son las únicas efectivamente que poseen una FK apuntando a "reglaspropiedades ", y como las otras dos no devuelven nada, no hay dependencias transitivas.
En ese contexto, si "preguntas" y "reglasxpropiedades" tienen correctamente definidas sus fK como ON DELETE CASCADE, no debería existir problemas. Lo que es posible es que el TRUNCATE no estuviese funcionando correctamente.
Normalmente TRUNCATE se parseaba como si fuese un DELETE, por lo que no traía problemas con FK. Pero luego se modificó y lo que hace en lugar de borrar registros es eliminar la tabla y volverla a crear, a menos que haya dependencias funcionales. Eso puede ser el origen del problema, si es que no está interpretando correctamente las FK, ya que al intentar destruir la tabla, no puede porque las otras dos todavía existen.

Creo que la mejor solución será hacerlo por partes, o bien usar DELETE.

¿Podrías postear los CREATE TABLE de las tres? Sería interesante verlo.

[RIVERMILLOS]

esta es una

Código MySQL:

CREATE  TABLE IF NOT EXISTS `ortegayb_btc`.`reglaspropiedades` (
  `idreglas` INT NOT NULL AUTO_INCREMENT ,
  `mensaje` LONGTEXT NOT NULL ,
  `imagen` MEDIUMTEXT NULL ,
  `valor` VARCHAR(100) NULL ,
  `idtitulo` INT NOT NULL ,
  `idaccionesreglas` INT NOT NULL ,
  PRIMARY KEY (`idreglas`) ,
  INDEX `idtitulo_fk_reglaspropiedades` (`idtitulo` ASC) ,
  INDEX `idaccionesreglas_fk_reglaspropiedades` (`idaccionesreglas` ASC) ,
  CONSTRAINT `idtitulo_fk_reglaspropiedades`
    FOREIGN KEY (`idtitulo` )
    REFERENCES `ortegayb_btc`.`titulos` (`idtitulos` )
    ON DELETE CASCADE
    ON UPDATE CASCADE,
  CONSTRAINT `idaccionesreglas_fk_reglaspropiedades`
    FOREIGN KEY (`idaccionesreglas` )
    REFERENCES `ortegayb_btc`.`accionesreglas` (`idaccionesreglas` )
    ON DELETE CASCADE
    ON UPDATE CASCADE)
ENGINE = InnoDB
 
 
 
 
 
CREATE  TABLE IF NOT EXISTS `ortegayb_btc`.`preguntas` (
  `idpreguntas` INT NOT NULL AUTO_INCREMENT ,
  `idreglas` INT NOT NULL ,
  `clase` VARCHAR(45) NOT NULL ,
  `metodo` VARCHAR(45) NOT NULL ,
  `valor` VARCHAR(100) NOT NULL ,
  PRIMARY KEY (`idpreguntas`) ,
  INDEX `idreglas_preguntas2op` (`idreglas` ASC) ,
  CONSTRAINT `idreglas_preguntas2op`
    FOREIGN KEY (`idreglas` )
    REFERENCES `ortegayb_btc`.`reglaspropiedades` (`idreglas` )
    ON DELETE CASCADE
    ON UPDATE CASCADE)
ENGINE = InnoDB
 
 
CREATE  TABLE IF NOT EXISTS `ortegayb_btc`.`reglasxpropiedades` (
  `idreglasXpropiedades` INT NOT NULL AUTO_INCREMENT ,
  `idreglas` INT NOT NULL ,
  `idpropiedad` INT(100) NOT NULL ,
  PRIMARY KEY (`idreglasXpropiedades`) ,
  INDEX `idreglas_fk_reglasxpropiedades` (`idreglas` ASC) ,
  INDEX `idpropiedades_fk_reglasxpropiedades` (`idpropiedad` ASC) ,
  CONSTRAINT `idreglas_fk_reglasxpropiedades`
    FOREIGN KEY (`idreglas` )
    REFERENCES `ortegayb_btc`.`reglaspropiedades` (`idreglas` )
    ON DELETE CASCADE
    ON UPDATE CASCADE,
  CONSTRAINT `idpropiedades_fk_reglasxpropiedades`
    FOREIGN KEY (`idpropiedad` )
    REFERENCES `ortegayb_btc`.`propiedades` (`idpropiedad` )
    ON DELETE CASCADE
    ON UPDATE CASCADE)
ENGINE = InnoDB
 

saludos

[gnzsoloyo]

Creo que ya lo encontré: La tabla reglasxpropiedades tiene dos FK, una apuntando a reglaspropiedaes, y otra a propiedades.
La cosa tiene dos niveles de error distintos:
Por un lado, esa es una tabla relacional, y las tablas relacionales no llevan su propia PK si no poseen otros datos en esa tabla (el ID autoincrement no cuenta, y no debería estar). La PK en este caso está compuesta por las FK de ambas tablas relacionadas (es lo que determina una relación N:N entre dos entidades o tablas). La forma en que la estás creando permite ingresar más de una vez la misma regla relacionada a la misma propiedad, lo que en definitiva significaría que puedes duplicar información. Eso no está bien.
Por otro, eso hace que intente borrar los registros de esa tabla relacional y puede que lo logre hacer, porque tiene alguna otra dependencia.
A mi me parece que el problema es que puedes estar generando dependencias circulares, y eso genera borrados imposibles.
Revisa que no estés poniendo FK en exceso.

[RIVERMILLOS]

Entonces deberia quitar la pk de reglasxpropiedades y dejar las dos fk como pk, lo ultimo de fk en exceso no te entindi muy bien? me podrias explicar.


saludos

[gnzsoloyo]

Vamos entonces aun poco de teoría:
Cuando tienes dos tablas que se relacionan entre si con cardinalidad N:N, significa que cada registro de la tabla A puede relacionarse con cero o más registros de la B, y que además cada registro de la B puede estar en más de uno de la A. Eso es una relación N:N, y por definición del modelo, requiere una tabla independiente en donde ambas PK se relacionen una vez por cada par vinculado.
El tema es que la relación única ya está dada por las dos PK que se ponen en esa tabla. Con declararlas ambas como PK al mismo tiempo, ya defines que no se puede repetir un vínculo jamás.
SI y sólo si un par puede repetirse por alguna razón, entonces debe ponersele una PK propia a esa tabla. Nada más.
Es el caso, por ejemplo, de turnos médicos: Un mismo médico puede tener consultas con el mismo paciente más de una vez, pero no en la misma fecha, por lo que la fecha es parte de la PK. ¿se entiende?
Es un ejemplo simple, pero por allí anda la cosa.

Lo de los excesos de FK se producen especialmente cuando tienes poca experiencia en bases de datos. Es muy habitual que el diseñador quiera "asegurarse" de tener todos los datos disponibles, y termina colocando FK donde no se necesitan, porque las relaciones están ya implícitas.
Si la tabla B depende de la A, y la C de la B, no necesito poner la FK de A en C. Esa relación es transitiva y por tanto si lo hago le estoy metiendo una redundancia de datos absolutamente innecesaria.
Imaginemos el detalle de una Factura. Tiene los ID de los productos, y las cantidades vendidas; pero no necesita tener además el ID del proveedor del producto, ya que eso lo puedo sacar directamente del código de producto vendido. ¿Se entiende?
El problema de excederse en meter las FK en tablas que no lo necesitan es que cuando haces un borrado, las FK generan restricciones que impiden algunos de ellos. Pueden darse dependencias ciculares.
Supongamos que D tiene la FK de A, pero B también, C tiene la de B y D tiene la de C. ¿Cuál tabla puedes borrar?
Respuesta: Ninguna. Se ha formado un circulo de dependencias.
Cuando empiezas a crear tablas y poner las FK puede suceder que al querer conectar todo con todo, sin saberlo estás creando una cadena circular como esa (tres, cuatro o más tablas en secuencia que dependen unas de otras).
Habría que revisar con cuidado y ver si no se está produciendo eso allí.

[RIVERMILLOS]

Hola mira ya realice todo lo que dijiste que tenias razon habian cosas como las que mencionas pero ya las modifique pero me sigue daliendo lo mismo esto...

Código:

#1701 - Cannot truncate a table referenced in a foreign key constraint (`ortegayb_btc`.`reglasxpropiedades`, CONSTRAINT `idreglas_fk_reglasxpropiedades` FOREIGN KEY (`idreglas`) REFERENCES `ortegayb_btc`.`reglaspropiedades` (`idreglas`))

Código MySQL:

CREATE  TABLE IF NOT EXISTS `ortegayb_btc`.`reglaspropiedades` (
  `idreglas` INT NOT NULL AUTO_INCREMENT ,
  `mensaje` LONGTEXT NOT NULL ,
  `imagen` MEDIUMTEXT NULL ,
  `valor` VARCHAR(100) NULL ,
  `idtitulo` INT NOT NULL ,
  `idaccionesreglas` INT NOT NULL ,
  PRIMARY KEY (`idreglas`) ,
  INDEX `idtitulo_fk_reglaspropiedades` (`idtitulo` ASC) ,
  INDEX `idaccionesreglas_fk_reglaspropiedades` (`idaccionesreglas` ASC) ,
  CONSTRAINT `idtitulo_fk_reglaspropiedades`
    FOREIGN KEY (`idtitulo` )
    REFERENCES `ortegayb_btc`.`titulos` (`idtitulos` )
    ON DELETE CASCADE
    ON UPDATE CASCADE,
  CONSTRAINT `idaccionesreglas_fk_reglaspropiedades`
    FOREIGN KEY (`idaccionesreglas` )
    REFERENCES `ortegayb_btc`.`accionesreglas` (`idaccionesreglas` )
    ON DELETE CASCADE
    ON UPDATE CASCADE)
ENGINE = InnoDB
 
CREATE  TABLE IF NOT EXISTS `ortegayb_btc`.`reglasxpropiedades` (
  `idreglas` INT NOT NULL ,
  `idpropiedad` INT(100) NOT NULL ,
  INDEX `idreglas_fk_reglasxpropiedades` (`idreglas` ASC) ,
  INDEX `idpropiedades_fk_reglasxpropiedades` (`idpropiedad` ASC) ,
  PRIMARY KEY (`idreglas`, `idpropiedad`) ,
  CONSTRAINT `idreglas_fk_reglasxpropiedades`
    FOREIGN KEY (`idreglas` )
    REFERENCES `ortegayb_btc`.`reglaspropiedades` (`idreglas` )
    ON DELETE CASCADE
    ON UPDATE CASCADE,
  CONSTRAINT `idpropiedades_fk_reglasxpropiedades`
    FOREIGN KEY (`idpropiedad` )
    REFERENCES `ortegayb_btc`.`propiedades` (`idpropiedad` )
    ON DELETE CASCADE
    ON UPDATE CASCADE)
ENGINE = InnoDB
 
 
CREATE  TABLE IF NOT EXISTS `ortegayb_btc`.`preguntas` (
  `idpreguntas` INT NOT NULL AUTO_INCREMENT ,
  `idreglas` INT NOT NULL ,
  `clase` VARCHAR(45) NOT NULL ,
  `metodo` VARCHAR(45) NOT NULL ,
  `valor` VARCHAR(100) NOT NULL ,
  PRIMARY KEY (`idpreguntas`) ,
  INDEX `idreglas_preguntas2op` (`idreglas` ASC) ,
  CONSTRAINT `idreglas_preguntas2op`
    FOREIGN KEY (`idreglas` )
    REFERENCES `ortegayb_btc`.`reglaspropiedades` (`idreglas` )
    ON DELETE CASCADE
    ON UPDATE CASCADE)
ENGINE = InnoDB
 

asi quedaron las tablas. despues de la modificaion no se que mas pueda ser?


saludos

[bulele]

Las tablas relacionadas deben borarse utilizando lo que se llama el borrado en cascada. Revisa la función ON DELETE CASCADE. Es la forma más simple de eliminar tablas relacionadas con key foreing

[gnzsoloyo]

Iniciado por bulele

Las tablas relacionadas deben borarse utilizando lo que se llama el borrado en cascada. Revisa la función ON DELETE CASCADE. Es la forma más simple de eliminar tablas relacionadas con key foreing

Lee la cadena de posts completa. Eso es precisamente lo que estamos tratando.
El problema es que hay alguna dependencia que no está apareciendo porque el CASCADE está funcionando, pero en alguna parte se corta y no hemos encontrado el punto donde falta, aún.

[RIVERMILLOS]

Pues ahora si funciono creo que si era lo de la relaciones N:N , pero habia como un error en mysql el soft como tal , lo que hice fue reintalarlo y ya funciono todo bn.


mil gracias.

[gnzsoloyo]

Genial. Me alegra que hayas salido adelante...