Diseño de base de datos de inventario [cerrado]

https://stackoverflow.com/questions/287097

08-07-2019
|

Pregunta

Esta no es una pregunta realmente acerca de la "programación" (no es específico de ningún lenguaje o base de datos), sino más de diseño y arquitectura. También es una cuestión del tipo "Cuál es la mejor manera de hacer X". Espero que no sea causa de mucho "religioso" controversia.

En el pasado, he desarrollado sistemas que, de una forma u otra, mantienen algún tipo de inventario de artículos (no importa qué artículos). Algunos usan idiomas / bases de datos que no admiten transacciones. En esos casos, opté por no guardar el artículo cantidad disponible en un campo en el registro del artículo. En cambio, la cantidad disponible se calcula totalizando el inventario recibido - total del inventario vendido. Esto ha resultado en casi ninguna discrepancia en el inventario debido al software. Las tablas están indexadas correctamente y el rendimiento es bueno. Existe un proceso de archivo en caso de que la cantidad de registros comience a afectar el rendimiento.

Ahora, hace unos años comencé a trabajar en esta empresa y heredé un sistema que rastrea el inventario. Pero la cantidad se guarda en un campo. Cuando se registra una entrada, la cantidad recibida se agrega al campo de cantidad para el artículo. Cuando se vende un artículo, la cantidad se resta. Esto ha resultado en discrepancias. En mi opinión, este no es el enfoque correcto, pero los programadores anteriores aquí lo juran.

Me gustaría saber si existe un consenso sobre cuál es la forma correcta de diseñar dicho sistema. También qué recursos están disponibles, impresos o en línea, para buscar orientación sobre esto.

Gracias

Solución

He visto ambos enfoques en mi compañía actual y definitivamente me inclinaría hacia el primero (calcular totales basados ??en transacciones de acciones).

Si solo está almacenando una cantidad total en un campo en algún lugar, no tiene idea de cómo llegó a ese número. No hay historial de transacciones y puede terminar con problemas.

El último sistema que escribí rastrea el stock almacenando cada transacción como un registro con una cantidad positiva o negativa. He encontrado que funciona muy bien.

Otros consejos

Tengo Vol. 1 y Vol. 2 y estos han sido muy útiles en el pasado.

Depende, los sistemas de inventario son mucho más que solo contar artículos. Por ejemplo, para fines contables, es posible que necesite conocer el valor contable del inventario basado en el modelo FIFO (Primero en entrar, primero en salir). Eso no puede calcularse por simple "totalizar el inventario recibido - total del inventario vendido" fórmula. Pero su modelo puede calcular esto fácilmente, ya que modifican el valor contable a medida que avanzan. No quiero entrar en detalles porque esto no es un problema de programación, pero si lo juran, tal vez no entendiste completamente todos sus requisitos que tienen que cumplir.

ambos son válidos, según las circunstancias. La primera es mejor cuando se cumplen las siguientes condiciones:

el número de elementos para sumar es relativamente pequeño
hay pocos o ningún caso excepcional a considerar (devoluciones, ajustes, etc.)
la cantidad del artículo de inventario no se necesita muy a menudo

por otro lado, si tiene una gran cantidad de artículos, varios casos excepcionales y acceso frecuente, será más eficiente mantener la cantidad de artículos

también tenga en cuenta que si su sistema tiene discrepancias, entonces tiene errores que deben rastrearse y eliminarse

He hecho sistemas en ambos sentidos, y ambos pueden funcionar bien, ¡siempre y cuando no ignores los errores!

Eche un vistazo al modelo de datos ARTS (Association for Retail Technology Standards) ( http://nrf-arts.org ). Utiliza una tabla StockLedger con un registro de cada artículo y todos los cambios en el inventario se rastrean en InventoryJournalEntries.

Es importante considerar el sistema existente y el costo y el riesgo de cambiarlo. Trabajo con una base de datos que almacena inventario como el suyo, pero incluye ciclos de auditoría y almacena ajustes al igual que los recibos. Parece que funciona bien, pero todos los involucrados están bien capacitados y el personal del almacén no es exactamente rápido para aprender nuevos procedimientos.

En su caso, si está buscando un poco más de seguimiento sin cambiar toda la estructura db, le sugiero que agregue una tabla de seguimiento (algo así como su solución de 'transacción') y luego registre los cambios en el inventario nivel. No debería ser demasiado difícil actualizar la mayoría de los cambios en el nivel de inventario para que también dejen un registro de transacciones. También puede agregar una tarea periódica para hacer una copia de seguridad del nivel de inventario en la tabla de transacciones cada dos horas más o menos para que, incluso si pierde una transacción, pueda descubrir cuándo ocurrió el cambio o volver a un estado anterior.

Si desea ver cómo una aplicación grande mira SugarCRM , tienen un inventario módulo de gestión, aunque no estoy seguro de cómo almacena los datos.

Creo que esta es en realidad una pregunta general de mejores prácticas sobre hacer un recuento (relativamente) costoso cada vez que necesita un conteo total frente a hacerlo cada vez que algo cambia, luego almacenar el recuento en un campo y leer ese campo cada vez necesitas un total.

Si no pudiera usar las transacciones, iría con el conteo en vivo cada vez que necesitara un total. Si hay transacciones disponibles, sería seguro realizar las operaciones de actualización de inventario y guardar el total contado nuevamente dentro de la misma transacción, lo que garantizaría la precisión del recuento (aunque no estoy seguro de que esto funcione con múltiples usuarios golpear la base de datos).

Pero si el rendimiento no es realmente un gran problema (y las bases de datos modernas son lo suficientemente buenas para contar filas que rara vez me preocuparía por esto), me quedaría con el conteo en vivo cada vez.

Optaría por la primera forma, donde

se calcula la cantidad disponible totalizando el inventario recibido - total de inventario vendido

La forma correcta, OMI.

EDITAR: también me gustaría tener en cuenta las pérdidas / daños en el sistema, pero estoy seguro de que tiene eso cubierto.

He trabajado en sistemas que resuelven este problema antes. Creo que la solución ideal es una columna calculada previamente, que te ofrece lo mejor de ambos mundos. Su total sería un campo en algún lugar, por lo tanto, no hay búsquedas costosas, pero no se puede sincronizar con el resto de sus datos (la base de datos mantiene la integridad). No recuerdo qué RDMS admiten columnas precalculadas, pero si no tiene transacciones, es posible que tampoco estén disponibles.

Podrías falsificar columnas precalculadas (de manera muy efectiva ... no veo inconvenientes) usando disparadores. Sin embargo, probablemente necesite transacciones. En mi humilde opinión, mantener la integridad de los datos cuando estás haciendo este tipo de desnormalización controlada es el único uso legítimo para un desencadenante.

Django-Inventory se orienta más a los activos fijos, pero podría darle algo ideas.

IE: ItemTemplate (clase) - > ItemsOnHand (instancia)

ItemsOnHand se puede vincular a más ItemTemplates; Impresora de ejemplo & amp; Se requieren los cartuchos de tinta. Esto también permite establecer puntos de pedido para cada ItemOnHand.

Cada ItemsOnHand está vinculado a InventoryTransactions, esto permite una auditoría fácil. Para evitar el cálculo de artículos reales disponibles a partir de miles de transacciones de inventarios, se utilizan puntos de control que son solo un saldo + una fecha. Para calcular los artículos disponibles, busque el punto de control más reciente y comience a sumar o restar artículos para encontrar el saldo actual de los artículos. Defina nuevos puntos de control periódicamente.

Puedo ver algún beneficio al tener las dos columnas, pero no estoy siguiendo la parte sobre las discrepancias: parece estar insinuando que tener las dos columnas (dentro y fuera) es menos propenso a la discrepancia que una sola columna ( corriente). ¿Por qué es eso?

No tiene una o dos columnas, lo que quise decir con "totalizar el inventario recibido - total del inventario vendido" es algo como esto:

Select sum(quantity) as inventory_received from Inventory_entry
Select sum(quantity) as inventory_sold from Sales_items

luego

Qunatity_on_hand = inventory_received - inventory_sold

Tenga en cuenta que simplifiqué demasiado esto y mi explicación inicial. Sé que hay mucho más en el inventario que solo hacer un seguimiento de las cantidades, pero en este caso ese es el problema y lo que queremos solucionar. En este punto, la razón para cambiarlo es precisamente el costo de soportar los problemas causados ??por el diseño actual.

También quería mencionar que aunque esto no es una "codificación" pregunta está relacionada con algoritmos y diseño, que en mi humilde opinión son temas muy importantes.

Gracias a todos por sus respuestas hasta ahora.

Nelson Marmol

Resolvemos diferentes problemas, pero nuestro enfoque para algunos de ellos puede ser interesante para usted.

Permitimos que el sistema haga una `` mejor suposición '' y proporcionemos a los usuarios comentarios regulares sobre cualquiera de esas suposiciones que parecen incorrectas.

Para aplicar esto al inventario, puede tener 3 campos:

inventory_received
inventory_sold
estimated_on_hand

Entonces, podría ejecutar un proceso (¿diario?) siguiendo las líneas de:

SELECT * 
FROM   Inventory
WHERE  estimated_on_hand != inventory_received - inventory_sold

Por supuesto, esto depende de que los usuarios vean esta alerta y hagan algo al respecto.

Además, podría tener una función para restablecer el inventario de alguna manera, ya sea actualizando inventario_vendido / recibido, o tal vez agregando otro campo '' inventario_ajuste '', que podría ser positivo o negativo.

... solo algunos pensamientos. Espero que sea útil.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow