campos calculados y cambio de valores futuros

[metratron]

Junto con saludarlos, me gustaría saber como es la mejor manera de estructurar la base de datos.

Tengo que hacer una aplicación de facturas donde tengo las tablas clientes, facturas, detalle_facturas y productos.

Una de las cosas que me gustaría es que en la tabla facturas se guardara en un campo el total de esta, osea el total de todos los productos vendidos. Pero la teoría dice que no se pueden almacenar datos calculados en la BBDD. Que lo mas factible seria que la aplicación sumara los productos cada vez que se llame a la factura y que ademas calcule el impuesto.

Pero esto genera otro problema, ya que al estar relacionadas la tabla facturas con detalle_facturas y productos via "id " y claves foraneas. Al cambiar el precio de algún producto en el futuro, al hacer un SELECT de una factura antigua no le variará el valor de esos productos pasados, ya que todos los valores se cambian en cascada.

Como puedo mantener los valores antiguos de las facturas pasadas en el momento que el usuario cambie los precios de los productos en la actualidad.


Ejemplo (solo si no quedo claro lo de mas arriba)


cada mouse sale 1.000 pesos chilenos en abril del 2010.



Factura 1 30/04/2010

cant Descripcion unitario total

2 mouse 1.000 2.000


iva 19% 380

Total 2.380



se sube el precio de los mouse de 1.000 a 1.500 el abril del 2013 y quiero ver la factura de el 2010




Factura 1 30/04/2010

cant Descripcion unitario total

2 mouse 1.500 3.000


iva 19% 570

Total 3.570

Si le subo el precio al mismo producto al cambiar por cascada, cambiara el valor de las facturas pasadas.

¿Como puedo bloquear el cambio de valores en el pasado?
¿Guardo el total de la factura en la table factura o solo la calculo vía aplicación cada vez que se quiera ver las facturas mas antiguas?

Saludos.

[gnzsoloyo]

¿Guardo el total de la factura en la table factura o solo la calculo vía aplicación cada vez que se quiera ver las facturas mas antiguas?

Por regla universal, no se guardan valores calculables. Es decir, no se ponen totales. Sólo lo que se necesita para reconstruir los datos. Sólo guardas datos calculados cuando almacenas ciertas informaciones que no se modificarán jamás (datawarehouses, por caso).
Pero en definitiva es algo que depende de lo que se está diseñando. Sin un relevamiento del sistema que se necesita no se puede asegurar nada.

Si le subo el precio al mismo producto al cambiar por cascada, cambiara el valor de las facturas pasadas.

¿Como puedo bloquear el cambio de valores en el pasado?

Eso es un tema algo complejo. No hay un manual práctico ni existe una única forma de diseñarlo.
Prácticamente hay tantas formas de hacerlo como sistemas hay en el mundo. Una de las soluciones tiene que ver con la creación de listas de precios, a las cuales la factura está asociada, por ejemplo.

[metratron]

Iniciado por gnzsoloyo

Por regla universal, no se guardan valores calculables. Es decir, no se ponen totales. Sólo lo que se necesita para reconstruir los datos. Sólo guardas datos calculados cuando almacenas ciertas informaciones que no se modificarán jamás (datawarehouses, por caso).
Pero en definitiva es algo que depende de lo que se está diseñando. Sin un relevamiento del sistema que se necesita no se puede asegurar nada.

Eso es un tema algo complejo. No hay un manual práctico ni existe una única forma de diseñarlo.
Prácticamente hay tantas formas de hacerlo como sistemas hay en el mundo. Una de las soluciones tiene que ver con la creación de listas de precios, a las cuales la factura está asociada, por ejemplo.

La primera parte la tengo mas que claro, no debí ni siquiera consultarlo, ya que es mas que obvio, mientras que la segunda me tiene colgado.

Ya que si tengo, las facturas asociadas a listas de precios, ¿cada vez que el usuario desee cambiar algún precio deberá hacer una nueva lista?.

Cuando sean muchos productos sera una tarea titanica, lo unico que deberia hacerse es cambiar tan solo los precios nada mas.

Yo se que me dijiste que no existen manuales que hablen sobre el tema, pero para googlearlo mejor, esto tiene algún nombre en particular para poder buscar y no molestarte mas con mis planteamientos, ya que todavía no tengo claro el concepto de usar una tabla intermedia que sea una lista de precios.

Saludos y muchas gracias.

[gnzsoloyo]

Ya que si tengo, las facturas asociadas a listas de precios, ¿cada vez que el usuario desee cambiar algún precio deberá hacer una nueva lista?.

Es un poco más complejo que eso, pero la idea es mas o menos esa.
Yo trabajo para una empresa que tiene enormes cantidades de listas de precios aplicables en diferentes momentos del tiempo, y para una enorme cantidad de categorías de clientes, en base a una ingente cantidad de variables, y para productos y servicios que se actualizan casi en forma diaria. No te puedes hacer una idea de lo complejo del sistema.
Pero aún con toda esa complejidad, el sistema de cálculo de precios de un mismo producto para un momento dado del tiempo, tienes una pasmosa simplicidad basada precisamente en ese esquema: Listas de precios que a su vez tienen versiones que se aplicaron en determinados periodos, las que tienen fecha de alta y baja. En consecuencia, determinar que lista tiene vigencia para una operación dada es relativamente sencillo.

Cuando sean muchos productos sera una tarea titanica, lo unico que deberia hacerse es cambiar tan solo los precios nada mas.

En realidad es bastante más simple de lo que crees. Como el esquema de dependencia de una lista de precios es dinamico, y semejante a la de detalle de una factura, lo que se hace es hacer actualizaciones masivas de precios en uno o más subprocesos específicamente diseñados para eso.
Las actualizaciones masivas, entonces, aplican sólo a los productos que se desea actualizar y los procesos recorren todas las listas de precio activas, creando una nueva versión automáticamente para aquellas que están afectadas.
Puede parecerte enredado, y en cierto sentido lo es, pero es efectivo.

[metratron]

Iniciado por gnzsoloyo

En realidad es bastante más simple de lo que crees. Como el esquema de dependencia de una lista de precios es dinamico, y semejante a la de detalle de una factura, lo que se hace es hacer actualizaciones masivas de precios en uno o más subprocesos específicamente diseñados para eso.
Las actualizaciones masivas, entonces, aplican sólo a los productos que se desea actualizar y los procesos recorren todas las listas de precio activas, creando una nueva versión automáticamente para aquellas que están afectadas.
Puede parecerte enredado, y en cierto sentido lo es, pero es efectivo.

Te creo que debe ser mas simple de lo que pienso, pero lo que dices es como si una persona que nunca en su vida ha visto una bicicleta, le dijeran "Es super simple tiene ruedas y unos ejes de metal", esa persona se puede imaginar que tiene 4 ruedas y es traccionado por caballos. Mientras que si le hicieras un dibujo se entendería claramente.

Para ti es fácil ver la estructura, pero para mi es difícil imaginármela por que no tengo claro el dibujo.

[gnzsoloyo]

Ejemplo de modelo de datos para facturas (invoices), productos (products), categorias o tipos de productos (product types) y pagos por tipo de pago (financial transactions):



Modelo de ejemplo para catalogos de productos (se puede usar el catalogo como base de lista de precios):

[gnzsoloyo]

Modelo genérico para proveedores:

[metratron]

Iniciado por gnzsoloyo

Ejemplo de modelo de datos para facturas (invoices), productos (products), categorias o tipos de productos (product types) y pagos por tipo de pago (financial transactions):

En este ejemplo si te fijas existe una tabla que repite los itemes de las lineas de la factura (invoice line items) aca repite el tipo de producto y el precio que viene de la tabla productos, esto me solucionaria el problema pero causa redundancia entre estas 2 tablas ya que repite datos entre una y otra y va en contra de las reglas de normalizacion. O por ultimo al estar multiplicado las unidades compradas por el precio al guardarlo es un resultado calculado, lo cual como pusiste mas arriba no se debe hacer.

Iniciado por gnzsoloyo

Modelo de ejemplo para catalogos de productos (se puede usar el catalogo como base de lista de precios):

Aca estoy traduciendo la tablas catalogos para plantearlas como listado de precios.

Saludos.