Ver la Versión Completa : incluir totales o no
reevil
06-05-2006, 05:35:42
hola...
la pregunta es:
¿conviene o no incluir un campo para totales en una tabla de mysql?
la mayoria (yo incluido) no lo recomienda, pero me surgio la duda de que sera mas importante , espacio en disco o desempeño...
supongamos algo como esto:
un sistema que genera facturas o liquidaciones con 3 tablas:
tbliquidacion con campos tipo int: idliq*,totalproduccion,totalprestamos.
tbproduccion con campos tipo int: idliq, produccion.
tbprestamos con campos tipo int: idliq, prestamo.
asi a simple vista hay quien diria que los campos totales no son necesarios y que solo aumentarian el tamaño de la base de datos... pero que tan importante es eso cuando tenemos dispositivos de almacenamiento sobrados?... no seria mas conveniente sacrificar un poco de espacio para hacer algunas consultas mas rapidas??
saludos...
Hola,
Pero, ¿qué te hace pensar que las consultas serían más rápidas? En La biblia de MySQL (http://www.casadellibro.com/fichas/fichabiblio/0,1094,2900000934987,00.html?codigo=2900000934987&titulo=LA+BIBLIA+DE+MYSQL+%28INCLUYE+CD-ROM%29) que estoy leyendo (y que por cierto recomiendo a todos, pues leer, aunque sea traducido a Ian Gilfillan resulta muy ameno) se trata sobre el tema en el sentido de que los cálculos que puedan delegarse al gestor de bases de datos es mejor delegarlos, por varios motivos.
Mezclaré a continuación una serie de motivos, unos directamente sacados del libro que menciono y otros añadidos por mi cuenta y riesgo. Se me ocurre que añadir un campo a una tabla de la base de datos está demás, cuando ese campo puede calcularse de la suma (por ejemplo) de dos campos de dicha tabla u otra, supongo.
Según el libro el que nuestra aplicación no se ocupe de lo que pueda ocuparse el gestor de bases de datos la convierte en más portable; el delegar, como ya he dicho, al gestor de la base de datos ciertos cálculos, como en este caso, puede redundar en una mejora en el rendimiento de la aplicación (y ahí iba yo antes con lo de que no sabes si las consultas resultarían más rápidas y menos costosas,... hasta que no lo pruebes, digo yo, vamos).
En fin, no me hagas tampoco mucho caso, porque recién comienzo en MySQL, pero, yo entendí más o menos lo que he tratado de explicar. Pueden todos corregirme, tú incluído, si ves que es menester. ;)
PD. Estoy seguro de que había más beneficios tratando de delegar (insisto) en el gestor de bases de datos las tareas de que puede ocuparse, y no llevarlas a cabo en nuestra aplicación, aun cuando fuera posible también llevar a cabo dichas tareas en ella.
roman
06-05-2006, 06:30:20
Según el libro el que nuestra aplicación no se ocupe de lo que pueda ocuparse el gestor de bases de datos la convierte en más portable
No entiendo muy bien esto. ¿Por qué la hace más portable?
// Saludos
roman
06-05-2006, 06:41:41
A ver, una cosa. Si el campo calculado se obtiene de otros campos de la misma tabla, ciertamente veo pocos beneficios en guardarlo. Pero en el ejemplo que se pone, el campo calculado es el producto de campos de distintas tablas. Se dice fácil multiplicar, pero para ello habrá que hacer dos joins:
select tblproduccion.produccion* tblprestamo.prestamo
from tbliquidacion, tblproduccion, tblprestamo
where
tblliquidacion.idliq = tblproduccion.idliq and
tblliquidacion.idliq = tblprestamo.idliq
y un join siempre toma tiempo. A lo mejor el caso expuesto es muy simplista pero pienso que no podemos afirmar que se puede prescindir siempre de guardar el cálculo. Dependerá en mucho del objetivo, quizá si se requieren muchos listados o reportes, convenga guardarlo.
// Saludos
Hola,
Bueno. Sin duda, revisando por encima de nuevo el capítulo cinco del libro que mencioné arriba, he debido confundir algunos conceptos y términos y hasta dónde puede llegarse con la portabilidad, porque, no encuentro escrito, efectivamente, algo que confirme lo que he dicho. Sin embargo, tal vez me equivocase de capítulo... tal vez estuviera en otro... lo que me hizo decir lo que dije, o fueron varios capítulos los que me han llevado a decirlo.
En fin. Puedo aceptar que en este caso en concreto no se consiga un código "más portable", aunque mantengo que considero mejor (más lógico, modestamente) el calcular un "total" a partir de uno o más campos, que no guardar un "total" en un campo aparte. Al menos así, sin conocer del todo de qué estamos hablando realmente, como norma general.
Por otro lado, lo de que fuera también más portable lo que pudiera resultar de hacerlo de ese modo, puede que me saliera de haber leído este párrafo introductorio del capítulo cinco del libro susomentado:
Como lograr codigo portable y sencillo de mantener
Basta con aplicar unos sencillos pasos para mejorar enormemente la flexibilidad del codigo. Entre ellos, se incluye el mantenimiento de los detalles de conexion aparte y dentro de una unica ubicacion asi como la construccion de consultas de base de datos de manera flexible para que los cambios futuros que se apliquen a la estructura de la base de datos no afecten a la aplicacion.
Y hasta ahí puedo llegar... ignoro cuánto de portabilidad añadirá en este caso en concreto a nuestra aplicación el aprovechar el gestor de la base de datos para realizar los cálculos precisos para conseguir un "total", lo que me parece que podría ser es que no restaría portabilidad, y, bueno, en todo caso, que no estaría demás tampoco.
Disculpad que no sepa hablar del tema, que no utilize bien ciertos conceptos, palabras, etc., pero, sobre esto, como sobre tantas cosas, estoy más bien pez. ;)
Hola,
A lo mejor el caso expuesto es muy simplista pero pienso que no podemos afirmar que se puede prescindir siempre de guardar el cálculo. Dependerá en mucho del objetivo, quizá si se requieren muchos listados o reportes, convenga guardarlo.
Por supuesto. Estoy de acuerdo. Pero, a lo mejor lo que sí se puede sacar en conclusión (aunque acaso ya me salga del tema completamente) es que mientras pueda utilizarse el gestor de bases de datos para realizar determinadas tareas, generalmente conviene que sea este quien se encarge de ellas y no nuestra aplicación.
Me permito citar otro párrafo del capítulo cinco del libro susomentado:
Cuanto trabajo deberia realizar el servidor de la base de datos?
Uno delos debates constantes entrelos desarrolladores es como deberia repartirse la carga de trabajo entre el servidor de la base de datos y la aplicacion.
En un primer momento,los desarrolladores de MySQL se mostraron muy a favor de delegar todo el peso en la aplicacion, en parte porque no incorporaba algunas funciones, como procedimientos almacenados y desencadenadores, y en parte por una cuestion de principios. Esta actitud les convirtio en objeto de criticas y la ausencia de estas funciones llevo a la gente a considerar a MySQL como una base de datos poco seria (una etiqueta de la que solo ahora, con la version 4, esta comenzando a superar).
En general, la base de datos deberia hacer todo el trabajo posible. (...)
reevil
06-05-2006, 07:01:01
hola de nuevo.
yo tambien he sido de la idea de preferentemente no utilizar campos para totales pero imaginemos esto:
liquidacion #1 esta formada por 5 producciones y 4 prestamos.
para saber el total de produccion neta de dicha liquidacion habria que hacer la suma de las 5 producciones y restarle la suma de los 4 prestamos...
y peor aun, si queremos la produccion neta desde la factura #1 hasta la #10,000 ... tendriamos que hacer la suma de todas las producciones donde idliquidacion este entre 1 y 10000 y a eso restarle la suma de todos los prestamos
si ponemos un campo totalneto, para cada liquidacion, solo seria un select que nos regrese la suma de los totales
supongo debe haber circunstancias donde se compliquen aun mas las cosas...
ahi es cuando me surge la duda si no conviene hacer trabajar practicamente nada al cliente al momento de insertar producciones y prestamos
saludos a todos
roman
06-05-2006, 07:05:47
Repito lo mismo. Hay que hacer un balance entre ser más papista que el papa y el rendimiento. En ocasiones, por ejemplo, conviene sacrificar normalización de la base en aras de rendimiento. Por otra parte esto no es tanto un problema de entre qué dejar a la aplicación y qué al motor de la base (*) sino de guardar o no un campo redundante.
(*) Y en cuanto a esto también hay muchas opiniones. El autor que mencionas tiene la suya pero también hay muchos que opinan en sentido contrario. Hasta donde entiendo, los procedimientos almacenados tienden a ser muy dependientes del motor y por ende, un uso excesivo de ellos hará el sistema poco portable a otros motores.
// Saludos
roman
06-05-2006, 07:10:22
Justamente reevil, ahora expones un caso mucho más realista. Los cálculos se complican y ante todo está el rendimiento, máxime que tales cálculos dependen ya no sólo de otras columnas sino de otros registros. No veo problema alguno en usar un campo extra.
// Saludos
reevil
06-05-2006, 07:13:45
Justamente reevil, ahora expones un caso mucho más realista...
:D cierto, creo que debi poner un ejemplo de cuando digo
no seria mas conveniente sacrificar un poco de espacio para hacer algunas consultas mas rapidas??
saludos a todos
Hola,
A ver, a ver, aclaremos algunas cosas... ;)
En primer lugar diré que, efectivamente, yo había pensado en un par de campos que hubieran de sumarse o multiplicarse o con los que realizar un cálculo, en fin, para obtener un total. Quizás no leí del todo bien el problema que planteaba el compañero y me lanzé a contestar, puesto que tengo bastante reciente lo leído en el libro de Ian Gilfillan.
Repito lo mismo.
Ya somos dos, entonces. ;)
Hay que hacer un balance entre ser más papista que el papa y el rendimiento.
Nadie habló de ser más papista que el papa hasta ahora. Sí se habló de que en general podría tenderse a una cosa, pero, por supuesto (¿cómo dudarlo?) habrían de tenerse en cuenta las necesidades de aquello que tuviéramos entre manos.
En ocasiones, por ejemplo, conviene sacrificar normalización de la base en aras de rendimiento.
Así he leído también en La biblia de MySQL, efectivamente. Aunque palabras como normalización (ni su sentido) están todavía muy lejanas de mi comprensión, lo cierto es que recuerdo haber leído que la normalización a veces (estamos otra vez en lo mismo: en el depende) tendría que supeditarse a otros objetivos.
Por otra parte esto no es tanto un problema de entre qué dejar a la aplicación y qué al motor de la base (*) sino de guardar o no un campo redundante.
Pero tú ya estás pensando en la normalización. ¿O me equivoco? Yo no lo decía por tanto, esto es, no había tenido en cuenta eso, para qué nos vamos a engañar.
Y en cuanto a esto también hay muchas opiniones. El autor que mencionas tiene la suya pero también hay muchos que opinan en sentido contrario.
¡Pues no faltaría más! Sin embargo, de lo poco que he leído a Ian Gilfillan (y traducido al español, y no pierde aún así, en mi opinión, cierto buen rollo que transmiten sus palabras) me parece un tipo bastante razonable y lo que propone bastante lógico, siempre en cuanto a mí me pueda parecer lógico un tema que me supera no poco.
Hasta donde entiendo, los procedimientos almacenados tienden a ser muy dependientes del motor y por ende, un uso excesivo de ellos hará el sistema poco portable a otros motores.
Aquí estamos como con la normalización. Simplemente, yo no había pensado en procedimientos almacenados, ni las consecuencias de su uso indiscriminado.
En fin. ¿Quién me manda a mí meterme en estos berenjenales? :D
roman
06-05-2006, 07:30:31
Simplemente, yo no había pensado en procedimientos almacenados
Tú no pero el autor que citas sí y lo hace en la cita que de él citas :D
// Saludos
Hola,
Tú no pero el autor que citas sí y lo hace en la cita que de él citas :D
Lo sé, lo sé, pero, no tiene nada que ver... el autor está desarrollando una idea (pensando en ella), el párrafo además está fuera de contexto; tú has pensado en ello porque sin duda vas más allá que yo; y yo, simplemente, no pensé en ello, porque no creí que fuera necesario para lo que nos ocupa, mejor dicho para lo que imaginé que podría estar ocupándonos, porque nunca pensé en más de dos campos "a calcular".
vBulletin v3.6.8, Derechos ©2000-2024, Jelsoft Enterprises Ltd.