Cita: entonces de igual forma debo poner:
nombre | cantidadperas | cantidadmanzanas | cantidadtotal
y al final un "total" de todas las cantidades totales
No. Una de las reglas generales del diseño de una base de datos relacional es que
no se ponen campos que deban contener valores que pueden ser calculados o que son el resultado de cálculos realizables por medio de funciones de agregación.
Esto se hace porque al DBMS
le lleva menos tiempo realizar ese cálculo en la ejecución de la sentencia, que el tiempo necesario para
levantar un campo adicional ya que este implica eventualmente
más tiempo de overhead, por el espacio adicional necesario para ese dato.
Si esto te parece superfluo, recuerda que un campo DECIMAL, DOUBLE o FLOAT insume 8 Bytes, lo que significa que 8.000 registros le suman al sistema un acceso a disco adicional y un bloque de datos
desperdiciado...
¿Se comprende la idea?
En lugar de eso, ponerlo en la sentencia select usando una función agrupada, implica 8 bytes x
N, siendo
N la cantidad de registros efectivamente devueltos. Esto implica que si consulta 84.000 registros para devolver 150 como resumen, eso significa un uso de
1200 bytes adicionales (estos son cálculos al vuelo, pero el esquema es ese), que
está muy lejos de los 11 bloques adicionales requeridos si hubiese un campo adicional en la tabla...
Corolario: Una de las claves del diseño de bases de datos es, también, que se debe ahorrar todo el espacio de datos necesario, porque
los medios de almacenamiento son finitos, y el exceso de bytes generan
cuellos de botella en los sistemas de transmisión (léase: Internet)
Nota: La única excepción a la primera regla son los
DataWarehouse, pero eso es otro tema totalmente diferente, que se basa en un paradigma distinto y apunta a sistemas de cierto tipo.