Relacion de herencia , modelo inventario

[RIVERMILLOS]

hola tengo que implementar un modelo de inventarios donde una persona puede tener en su inventario varios tipos de objetos , pienso que esto se hace con una "herencia" mas a o menos así lo tengo.

INVENTARIO
---------------
IDINVENTARIO
IDUSUARIO
DATE


OBJECTO1
--------------
IDOBJECTO1
NOMBRE
IDINVENTARIO
IDOTRATABLA

OBJECTO2
--------------
IDOBJECTO2
NOMBRE
IDINVENTARIO
IDOTRATABLA


pero tengo un problema que al querer borrar todo el inventario

TRUNCATE INVENTARIO;

sale esto

Código:

Cannot truncate a table referenced in a foreign key constraint (`btc`.`objecto1`, CONSTRAINT `idinventary_FK_objecto1`
 FOREIGN KEY (`idinventary`) REFERENCES `btc`.`inventary` (`idinventary`))

No deberi borrar todo en casada.?


saludos

[gnzsoloyo]

La cascada se produce sólo cuando borras una tabla base, es cierto, pero la PK de esa tabla, en ese caso, debe tener el CASCADE definido en todas, absolutamente todas las tablas donde aparezca como FK.
Si hay al menos una FK que no tenga el ON DELETE CASCADE, no funcionará.

[RIVERMILLOS]

Muchas gracias por tu respuesta, existe alguna manera de saberl que fk tiene en otra tabla con una consulta o toca manualmente?
Saludos

[gnzsoloyo]

En realidad, si existe una forma, pero no es consultando la tabla, sino la base information_schema, que es la que contiene la descripción de cada esquema que haya en el servidor (entendiendo por esquema a cada base de datos creada), y cada elemento de ese esquema.

Código MySQL:

SELECT DISTINCT TABLE_NAME
FROM information_schema.KEY_COLUMN_USAGE K
WHERE REFERENCED_TABLE_NAME = 'inventary';
 

Devuelve, por ejemplo, la lista de tablas que se relacionan con INVENTARY por medio de FK.
Ten en cuenta que las tablas information_schema son sensibles a mayusculas/minusculas, por lo que si buscas una columna dada en la tabla COLUMNS, "idProducto" se considera diferente a "IDProducto", por ejemplo.

[RIVERMILLOS]

Hola , ya hice la consulta y el resultado es que la tabla inventary solo tiene un llave FK en otra las otras 3 tablas que heredan de ella no mas y estas están todas en casada? No se si mas bien es que el modelo que implemente no es el correto.



Saludos

[gnzsoloyo]

Entonces es un problema de cascada indirecta.
Te explico:
Si tienes una tabla base, y todas las FK que se refieren a ella, tienen la clausula ON DELETE CASCADE, se supone que deben poder borrarse todos los registros deesas tablas al borrar el registro base. Hasta allí, todo va OK.
Pero si alguna de las tablas secundarias, a su vez es referica como FK desde una tercera tabla, y esa tabla no tiene definida la condición ON DELETE CASCADE, no se podrá borrar el registro, y como consecuencia, tampoco te dejará borrar la tabla secudnaria, lo que trae como consecuencia final que a tabla base tampoco se puede borrar...
¿Se entiende?
En esencia es una telaraña: Tendras que seguir todas las dependencias de FK desde la tabla base y hasta el final, incluyendo las dependencias no directas.
En alguna parte hay una FK que está trabando todo. Y no necesariamente es una dependencia de la tabla base.

[RIVERMILLOS]

Ok , entonces voy hacer seguimiento de las llaves a ver cual esta tirando todo, tengo otra duda , es lo mismo hacerle un TRUNCATE a una tabla base que hacer le un DELETE FROM? Se deberia comportar igual?


saludos

[gnzsoloyo]

Se comportan mas o menos parecido, pero hay algunas diferencias.

- Las operaciones de truncado destruyen y recrean la tabla, que es mucho más rápido que borrar registros uno a uno.

- Las operaciones de truncado no son transaccionales; ocurre un error al intentar un truncado durante una transacción o un bloqueo de tabla.

- No se retorna el número de registros borrados.

- Mientras el fichero de definición de la tabla tbl_name.frm sea válido, la tabla puede recrearse como una vacía con TRUNCATE TABLE, incluso si los ficheros de datos o de índice se han corrompido.

- El tratador de tablas no recuerda el último valor AUTO_INCREMENT usado, pero empieza a contar desde el principio. Esto es cierto incluso para MyISAM y InnoDB, que normalmente no reúsan valores de secuencia.