Unificar o minimizar consulta MySQL

[The_Black_Edward]

Hola buenos dias... Como yo puedo generar una consulta donde yo relaciono hasta 3 trablas de una DB.

Como por ejemplo:

TABLA 1
sumando1= 5
sumando2=5
total=10

TABLA 2
sumando1=8
sumando2=6
total=14

TABLA 3
sumando1=4
sumando=1
total=5

La consulta que necesito es que me sume todo lo que tengo en cada columna llamada sumando1, sumando2 y total.

sumando1: 5+8+4:17
sumando2: 5+6+1:12
total: 10+14+5:29.

Por favor alguien que me ayude...

[huesos52]

Código SQL:

SELECT 
SUM(T1.total1),
SUM(T1.total2),
SUM(T1.total3)
FROM 
(SELECT tabla1.sumando1 AS total1,
              tabla1.sumando2 AS total2,
              tabla1.sumando3 AS total3
 FROM tabla1
UNION ALL
SELECT tabla2.sumando1 AS total1,
              tabla2.sumando2 AS total2,
              tabla2.sumando3 AS total3
 FROM tabla2
UNION ALL
SELECT tabla3.sumando1 AS total1,
              tabla3.sumando2 AS total2,
              tabla3.sumando3 AS total3
 FROM tabla3)T1;
 

[The_Black_Edward]

Ok. Muchas gracias huesos52. Otra pregunta... Cuantas tablas puedo yo llegar a relacionar con este tipo de consulta?

[huesos52]

N tablas.
Sin embargo, entre mas tablas, mas se verá afectado el rendimiento.
saludos

[The_Black_Edward]

Sera que si yo relaciono 7 tablas, esa cantidad podria afectar el rendimiento como tu dices?

[gnzsoloyo]

No hay un único factor intervniente. Si cruzas 7 tablas con 50 registros cada una no es lo mismo que cruzar 7 tablas con 2.5000.00 de registros en cada una...

Depende de varios factores:

- Longitud de claves y registros.
- Cantidad de registros afectados.
- Diseño de índices y su selectividad.
- Dispersión de datos seleccionados.
- Condiciones de búsqueda.
- Hardware usado (Micro, RAM, discos, etc.).
- Topología de la red.
- Versión del DBMS.

Optimizar una consulta a veces no es simplemente reescribirla...

[The_Black_Edward]

Yo voy a relacionar las 7 tablas y cada una tiene 170 columnas...!!! Seria bien relacionarlas o que otro metodo me pueden aconsejar para relacionar las 7 tablas?

[huesos52]

170 columnas?
Acá el problema parece ser de diseño de la base de datos.

No te queda otra que probarlo tu mismo.

saludos

[gnzsoloyo]

Estoy de acuerdo.
Que haya tablas con 170 columnas me habla o de una tabla con información sumamente compleja, o una tabla mal diseñada y con falta de normalización.
¿Qué tipo de entidad requiere 170 campos?

[The_Black_Edward]

Es una tabla con información sumamente compleja, en ella se almacenan tres registros, como por ejemplo... 4 + 4 = 8. Cada numero es un input, entonces si realizamos la suma de primer numero en input seria la siguiente, 24 input + 24 input que seria el siguiente numero que coloque en el ejemplo anterior y los ultimos 24 input que serian los del resultado igual a 8. Si sumamos todos esos input me deben de dar un resultado de 72 input, pero aqui viene lo mas importante... Esta tabla esta dividida por meses. Osea los primeros 72 input son del mes de enero, los otros 72 input serian del mes de febrero y los otros 72 input serian del mes de marzo. No se si me explique bien gnzsoloyo.

[gnzsoloyo]

Si, te has explicado: Lo que tienes es una tabla desnormalizada con montones de problemas de optimización a futuro...

[The_Black_Edward]

Ok. gnzsoloyo. Que me recomiendas hacer con ese detalle de la tabla o con el proceso que realizo para guardar?

[gnzsoloyo]

Si cada mes de cada año tienes 24 datos numéricos a ingresar, en realidad tienes una tabla de 4 campos: Tabla(anio, mes, dato_id, dato)
Los primeros dos definen a qué período pertenecen, y el tercer campo identifica el subitem de dato, y va numerado de 1 a 24. El último es dato real.
En este contexto, los campos se deben definir:
Tabla(
anio SMALLINT UNSIGNED,
mes TINYINT UNSIGNED,
dato_id TINYINT UNSIGNED, ,
dato INT UNSIGNED);

En esta forma, cada registro tendría 15 Bytes de longitud, contra una longitud que no puedo definir porque no detallas la estructura de los campos, pero supongo que debe ser mucho más extensa.
En este caso, se puede recuperar la misma estructura de datos, todos los 170 campos si quieres, en la consulta, sin necesidad de tener que crearlos.

Un par de consejos para la normalización que te pueden resultar útiles para evitar fallas de diseño:

- No se deben guardar datos calculables. Si tienes un campo C que representa la suma de los campos A y B, el C es superfluo, porque el resultado se puede crear en la consulta..
- No se deben usar campos más grandes de lo necesario. Si tienes un campo cuyo valor no superará el 12, no tiene sentido poner un INT, que tiene 4 Bytes, cuando un TINYINT alcanza, y tiene 1 byte (no te olvides que los números se guardan como binarios y no como cifras).
- Si tienes esquemas repetidos, como ha sido el caso de los meses en un mismo registro, esos pertenecen a otra tabla vinculada, o bien, el esquema entero puede ser simplificado.

[The_Black_Edward]

Ok. gnzsoloyo. Muchas gracias... La verdad que me aclarastes muchas dudas...

[gnzsoloyo]

Creo que lo que sí me olvidé mencionar es que los primeros tres campos (anio, mes, dato_id) componen la PK de la tabla...
Un olvido.