¿Qué camino es mejor para almacenar información de ventas en una base de datos:Al hacer los cálculos
Yo diría que siempre almacena el costo y el precio como columnas separadas Y almacena el total. Habrá un momento en que necesitará aquellos desglosados (informes, facturación) de los que se arrepentirá.
La pregunta realmente se convertirá en caso de que almacene también los valores calculados. eso realmente dependerá de las circunstancias de la aplicación (cuántas filas, cuántas transacciones, etc.). Si se trata de una aplicación pequeña - mediana, probablemente no importará el rendimiento, por lo que solo se trata de otros factores.
Si la fórmula para el total puede llegar a ser más complicado (ej. Impuestos, descuentos, etc ..), es posible que desee almacenar el total. de lo contrario, tener que replicar esa lógica en otras áreas puede resultar extremadamente difícil.
Yo personalmente siempre almaceno la cantidad total también. Solo encuentro que el costo de la columna de la base de datos adicional siempre se ve superado al tener ese total en otros lugares.
En la continuación de su idea, @Cody C, sin mencionar que los valores calculados almacenados pueden mejorar el rendimiento al cargar y/o informar cuando llegue el momento. De hecho, es más fácil hacer informes con campos calculados almacenados. Siempre depende del tipo de cálculos que necesita realizar. –
También es posible que desee tener esos campos calculados accesibles a través de algunas propiedades de solo lectura donde solo se requiere el captador, ya que el software debe poner valores en ellos, ya que se calculan. Estos setters serían utilizados solo por la capa de persistencia. –
Iría con el almacenamiento del costo de un artículo y el precio de venta por artículo. Si solo está almacenando los totales, tendrá dificultades para volver a calcular sus valores si los precios cambian. Imagínese dar un descuento estacional en algunos de sus artículos, aplicando diferentes impuestos a algunos artículos (tal vez incluso diferentes dependiendo del país de origen del cliente) u otorgando precios más bajos para los clientes registrados: tendrá que calcular esos precios según las ventas precio de un artículo, los totales no son útiles en este caso.
Y si realmente necesita los totales, ellos se puede calcular fácilmente cualquier momento usando simples DB-consultas, teniendo en cuenta todos los descuentos, etc., etc.
mi humilde opinión costo tienda y ventas por artículo. Si desea que los resultados vengan como totales, realicelos dentro de la consulta o cree una tabla temporal o un procedimiento almacenado con los cálculos. Sin embargo, generalmente realizo esos cálculos en el código (PHP o JAVA en mi caso). Si solo es para fines de informe, a veces está bien almacenar los totales para acelerar los cálculos (y evita algunos cálculos erróneos en su código).
Este es el problema 3rd Normal Form.
La opción 1 está en la 3ra forma normal. No hay datos derivados. El cálculo debe hacerse para cada consulta. Debido a esto, las actualizaciones se pueden hacer en cualquier campo sin romper nada.
La opción 2 rompe la tercera forma normal. Guarda datos derivados. Los cálculos no se realizan en el momento de la consulta, lo que los hace mucho más rápidos. Sin embargo, una actualización que no vuelva a hacer el cálculo dará lugar a datos inconsistentes. Esto se llama una "anomalía de actualización". Una actualización causa que el campo de datos derivados sea inconsistente.
Además, dependiendo del cálculo, puede ser imposible razonar qué campos deberían cambiar cuando los datos derivados deban modificarse.
Ah, pero si lo diseñó correctamente, una actualización arreglará los datos agregados. De hecho, no debes hacer esto a menos que te asegures de que se actualice. – HLGEM
@HLGEM: ¿"diseñó correctamente"? ¿Qué significa eso? Con un gatillo o algo? –
Depende de lo que esté haciendo, puede significar con un desencadenante o puede significar con un campo de calibración – HLGEM
tienda todos los detalles individuales para cada elemento, ya que por lo general los necesitará más adelante (con fines estadísticos/de información o cualquier otra razón).Debe asegurarse de seguir siempre la misma lógica de cálculo para obtener el precio total de venta. Entonces quizás tenga que almacenar monedas, descuentos, unidades de precios, etc. junto con estos. Aquí algunos puntos más a tener en cuenta:
Si desea que el precio único artículo más adelante, necesita los datos de un solo artículo.
No guarde el precio total junto con los datos de un solo artículo, ya que deberá mantener ambos sincronizados. Te desconcertarás algunos meses/años después, sobre cuál de los dos usarás para tus cálculos.
Agregue sus datos si los está utilizando en un almacén de datos y no necesita los detalles.
yo sólo almacenar los totales si tengo un problema de informes grave, donde muchas consultas requieren que el valor total de un gran conjunto de registros (si sólo está recibiendo el total para un conjunto pequeño, calcuating que enla mosca cuando lo solicite, está bien).
Si almacena los totales, necesita desencadenantes para asegurarse de que las actualizaciones, las eliminaciones y las inserciones actualicen correctamente los totales. De lo contrario, los datos estarán fuera de sincronía e inútiles.
Depende de lo que va a hacer con los datos.
Para muchos propósitos, vale la pena almacenar, en cada artículo, el precio unitario de ese artículo, la cantidad comprada y el precio extendido. El precio extendido es la cantidad multiplicada por el precio unitario. ¿Esto es redundante? bueno, sí. ¿Viola alguna forma normal? Bueno, sí. Pero funciona bastante bien.
¿Por qué almacenar el precio en la fila de artículos (registro) y no solo confiar en los mismos datos de precios almacenados en la tabla de productos maestros? Porque si cambia el precio después de esta venta, no desea cambiar el precio en que incurrió este cliente en esta compra. ¿Por qué almacenar el precio extendido, ya que esto puede ser recalculado sobre la marcha? Porque hace que sea un paso más simple agregar (suma o promedio) a un conjunto de elementos más adelante.
Si almacena el precio extendido, puede usar esos puntos y hacer clic, profundizar en las herramientas de análisis (ver OLAP) para un análisis posterior, sin más programación. Si cuenta con volver a calcular el precio extendido cuando lo necesite, puede descubrir que la herramienta de desglose no es lo suficientemente inteligente como para multiplicar por usted.
"elementos" normalmente serán elementos secundarios de alguna unidad de trabajo más grande. En un sistema de facturación, un artículo es parte de una factura. En un sistema de contabilidad general, un artículo es parte de una transacción. Los elementos no están equilibrados, pero la transacción sí lo está. En muchos sistemas de comercio actualmente, la función de facturación y la función de contabilidad se eliminan de la misma base de datos, pero eso va más allá de su pregunta.
Normalmente, trato de mantener mis datos normalizados. Este es un lugar donde muchos expertos se desvían intencionalmente de los requisitos de la normalización pura.
"Mejor"? ¿Qué significa "Mejor" en este contexto? Hay compensaciones específicas. ¿Qué es más importante para ti? –