Consulta de codigo

[gnzsoloyo]

En Desde_Código se guarda si es teclado,mouse, laptop etc. Lo que veo es que deberia de agregarle un campo donde se almacene la cantidad de los equipos para así poder contarlos no? Yo agrego varios objetos con un mismo código en maleta pero la descripción de los códigos será distinta, quiero que al consultar el código maleta me muestre cada uno de los Desde_Código agregados para el mismo código maleta i

No, desde el punto de vista de base de datos eso es un error de los severos. Es precisamente a ESO a lo que me referia con un error de diseño.
Estás planteandote la base de datos con lógica de programación, y no es lo mismo. Si lo haces de ese modo terminarás generando información redundante e inconsistente.
Lo que necesitas es un conjunto de tablas que administren las relaciones de una forma eficiente y consistente.
Lo que tienes es:
- Despachos de 1 o N maletas, a 1 o N municipios.
- Maletas, que se despachan conteniendo 1 o N componentes.
- Uno o N componentes de cada maleta.
- N cantidad de componentes en existencias.
- Cada componente perteneciente a una X categoría.
En ese caso hay tablas como:
- Municipio
- Despacho.
- Despacho_maletas.
- Maleta.
- Detalle_Maleta
- Componente.
- Categoria.
Esto por lo menos.
Voy a ahacer una suposición de que un Despacho es algo diferente a una maleta, y que un mismo despacho puede relacionarse con N maletas. No se si se da, pero lo planteo así
Detalle_Maleta es la tabla que administra la relación de qué hay y que cantidad. Tiene una relación de cardinalidad 1:N con maleta, y de 1:1 con Componente.
Componente a su vez tiene una relación N:1 con categoría, por que en Componente almacenarías uno a uno los objetos individuales, mientras que en categoría especificarías qué tipo de objeto es (laptop, mouse, teclado, etc.)

Con un esquema así, calcular cuántos componentes y de qué tipo tiene cada maleta es sencillo.
Supongamos que quieres ver cuántos componentes hay en cada maleta.

Código MySQL:

SELECT d.Maleta, d.CVA, m.Municipio, d.Parroquia, COUNT(dmt.componente_id) totalcontenido
FROM despacho d  
    INNER JOIN despacho_maleta dm ON d.despacho_id = dm.despacho_id
    INNER JOIN detalle_maleta dmt ON dm.maleta_id = dmt.maleta_id
    INNER JOIN municipio m ON d.Municipio = m.Cod_Municipio 
GROUP BY d.Maleta, d.CVA, m.Municipio, d.Parroquia;
 

O si van cantidades diferentes del mismo componente en la maleta, y quieres saber las categorías diferentes, sería mas o menos:

Código MySQL:

SELECT d.Maleta, d.CVA, m.Municipio, d.Parroquia, COUNT(DISTINCT dmt.componente_id) totalcontenido
FROM despacho d  
    INNER JOIN despacho_maleta dm ON d.despacho_id = dm.despacho_id
    INNER JOIN detalle_maleta dmt ON dm.maleta_id = dmt.maleta_id
    INNER JOIN municipio m ON d.Municipio = m.Cod_Municipio 
GROUP BY d.Maleta, d.CVA, m.Municipio, d.Parroquia;
 

Podemos seguir, pero si estás planteando las tablas de esa forma es que no has profundizado en el paradigma relacional, y tu base no cumple con los fundamentos del modelo Entidad-Relación.
¿Has verificado eso?

Nota: Si estas consultas te resultan complicadas, deberías ver las que usamos en la emrpesa, en el mundo real...