incluir totales o no

[dec]

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:

Empezado por Ian Gilfillan

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.

[dec]

Hola,

Empezado por Román

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:

Empezado por Ian Gilfillan

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. (...)

[roman]

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]

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]

Empezado por roman

Justamente reevil, ahora expones un caso mucho más realista...

cierto, creo que debi poner un ejemplo de cuando digo

Empezado por reevil

no seria mas conveniente sacrificar un poco de espacio para hacer algunas consultas mas rapidas??

saludos a todos

[dec]

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.

Empezado por Román

Repito lo mismo.

Ya somos dos, entonces.

Empezado por Román

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.

Empezado por Román

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.

Empezado por Román

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.

Empezado por Román

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.

Empezado por Román

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?

[roman]

Empezado por dec

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

// Saludos

[dec]

Hola,

Empezado por Román

Tú no pero el autor que citas sí y lo hace en la cita que de él citas

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".