¿Diseño de base de datos?

Question

Tenemos un proyecto relacionado con ventas.

Ahora mantenemos el stock de los productos en una tabla separada llamada Stock. En el momento de las ventas, el retorno de las ventas, la compra y el retorno de la compra, se actualizará la tabla de existencias. Funciona bien, pero mientras eliminamos o modificamos una de las ventas o compras, es más difícil mantener las existencias.

Le dije a mi jefe, que no queremos mantener el stock en una tabla separada, sino que escribimos una función para calcular el stock de tablas relacionadas (sales, purchase, ...). Cuando el usuario desea conocer el stock, llama a la función para obtener el stock con mucha facilidad. Por lo tanto, no necesitamos pensar en el mantenimiento del stock. Creo que es una buena idea

Pero me dijo que, si vienen muchos registros, la función tardará más tiempo en ejecutarse y reducirá la eficacia del software. No sé si eso es correcto o no. Una cosa que sé es que va en contra de la normalización de DB. No necesitamos mantener los valores calculados dentro o fuera de la tabla.

¿Cómo podría diseñar esta base de datos? ¿Es una tabla separada Stock mejor o no?

Answer 1

Hay un excelente estudio sobre ese tema here, por Allen Browne.

Answer 2

En general, es mejor tener una base de datos normalizada. Si tiene duplicación de datos y el software un día no funciona como debería, entonces podría terminar con datos inconsistentes, lo que no es bueno para nadie.

Para la mayoría de los propósitos, los cálculos pueden ser lo suficientemente eficientes como para que pueda hacerlos en los datos brutos, como sugiere. Si esto presenta un problema de escalabilidad para su proyecto en particular, tal vez sería mejor tener una tabla con los valores calculados. Esto nunca se trataría como datos originales y podría recalcularse en cualquier momento. Entonces sus datos están seguros, y sus cálculos son rápidos.

La otra alternativa, dependiendo de su DBMS, es considerar una vista.

Answer 3

¿Cuál es el contenido de su tabla de valores? ¿Tiene diferentes acciones donde se puede almacenar el mismo producto? Si solo hay una sola acción, desaconsejaría una tabla separada o un stock calculado. Calcular el stock puede ser bastante complejo y consumir mucho tiempo, especialmente si su consulta es más frecuente que realizar actualizaciones. Debería hacer que la cantidad de stock sea parte de su tabla de productos.

Answer 4

En general, desea una mayor normalización para mantener la integridad de los datos, y esto también tiende a optimizar la actualización de datos (no es necesario actualizar la misma información en más de un lugar). La única excepción real a esto es si su base de datos se usará principalmente para informar, y solo ocasionalmente se actualizará. Luego, el costo de actualizar en varios lugares diferentes (porque está desnormalizado) lo paga el hecho de que no tiene que buscar información de muchos lugares diferentes cuando informa.

Si su base de datos tiene que ser rápida para las transacciones (actualización), y solo ocasionalmente informar, luego normalizar tanto como sea posible. También es más fácil mantener todos los datos consistentes de esta manera. Sin embargo, si solo está actualizando de vez en cuando, y principalmente informando (es decir, leyendo, o simplemente extrayendo datos de la base de datos), entonces su jefe podría estar en lo cierto y podría ser una mejor opción denormalizarse. Sin embargo, es más complicado manejar las condiciones de error y mantener la integridad de los datos (hay que pensar más sobre lo que es una "transacción lógica" y cuándo hacer una copia de seguridad de todas las actualizaciones realizadas hasta el momento cuando algo sale mal).

Answer 5

¿Ha pensado en utilizar activadores para actualizar la tabla de stock?

En un mundo perfecto, la suma de todos los cambios es igual a la cantidad actual de artículos en stock. En el mundo real, la suma de los cambios es más un predictor estadístico del número de artículos en existencia. Si desea que el mundo real sea perfecto, tendrá que dar cuenta de todos los cambios posibles en ese número. Entonces, además de la compra y venta, necesita tipos de transacción para acciones iniciales, robo, desastre natural, donación a la cruz roja, etc. Necesitaría transacciones ficticias para corregir el recuento si el predictor y el número real de elementos divergen por algún imprevisto razón. Todo eso va a desordenar sus tablas de transacciones.

El argumento de rendimiento de su jefe también es válido. Cada vez que necesita la cantidad de artículos en existencia, debe sumar todas las transacciones. Si tiene muchos de ellos, esto puede convertirse en un cuello de botella de rendimiento, incluso si indexa correctamente la tabla de transacciones para que pueda hacer la suma del índice.

Y no estoy completamente de acuerdo en que la tabla de existencias viola la normalización. La cantidad de artículos que tiene en existencia en este momento, y la cantidad de artículos que se compran o venden conceptualmente no son los mismos, son números diferentes que están vinculados por la regla de negocio de que su empresa los está comprando y vendiendo (en lugar de que la fabricación y donándolos a la Cruz Roja), y como se describió anteriormente, están perfectamente correlacionados solo en un mundo perfecto.