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:
Cita:
|
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.
