Conception de la base de données d'inventaire [fermé]

https://stackoverflow.com/questions/287097

08-07-2019
|

Question

Cette question ne concerne pas vraiment la "programmation". (n'est spécifique à aucune langue ou base de données), mais plus de design et d'architecture. C'est aussi une question du type "Quelle est la meilleure façon de faire X". J'espère que cela ne causera pas trop de "religieux" controverse.

Dans le passé, j'ai développé des systèmes qui, d'une manière ou d'une autre, conservaient une forme quelconque d'inventaire des articles (non pertinents). Certains utilisent des langages / bases de données qui ne prennent pas en charge les transactions. Dans ces cas, j’ai choisi de ne pas enregistrer la quantité d’article en stock dans un champ de l’enregistrement de l’article. À la place, la quantité en stock est calculée en faisant le total des stocks reçus - le total des stocks vendus. Cela n’a entraîné pratiquement aucune différence dans les stocks en raison des logiciels. Les tables sont correctement indexées et les performances sont bonnes. Il existe un processus d’archivage dans le cas où la quantité d’enregistrements commence à affecter les performances.

Maintenant, il y a quelques années, j'ai commencé à travailler dans cette entreprise et j'ai hérité d'un système de suivi des stocks. Mais la quantité est enregistrée dans un champ. Lorsqu'une entrée est enregistrée, la quantité reçue est ajoutée au champ de quantité pour l'article. Lorsqu'un article est vendu, la quantité est soustraite. Cela a entraîné des divergences. À mon avis, ce n'est pas la bonne approche, mais les programmeurs précédents ne jurent que par elle.

J'aimerais savoir s'il existe un consensus sur la meilleure façon de concevoir un tel système. De plus, quelles ressources sont disponibles, imprimées ou en ligne, pour obtenir des conseils à ce sujet.

Merci

La solution

J'ai vu les deux approches dans mon entreprise actuelle et je pencherais certainement pour la première (calcul des totaux en fonction des transactions sur actions).

Si vous ne stockez qu'une quantité totale dans un champ quelque part, vous ne savez pas comment vous en êtes arrivé à ce nombre. Il n'y a pas d'historique transactionnel et vous pouvez vous retrouver avec des problèmes.

Le dernier système que j'ai écrit suit le stock en stockant chaque transaction sous forme d'enregistrement avec une quantité positive ou négative. J'ai trouvé que cela fonctionne très bien.

Autres conseils

J'ai les volumes 1 et 2 et ceux-ci ont été très utiles dans le passé.

Cela dépend, les systèmes d’inventaire vont bien au-delà du simple comptage des articles. Par exemple, à des fins de comptabilité, vous devrez peut-être connaître la valeur comptable des stocks en fonction du modèle FIFO (premier entré, premier sorti). Cela ne peut pas être calculé simplement par "total des stocks reçus - total des stocks vendus". formule. Mais leur modèle peut calculer cela facilement, car ils modifient la valeur comptable au fur et à mesure. Je ne veux pas entrer dans les détails car ce n’est pas un problème de programmation, mais s’ils jurent, vous n’avez peut-être pas bien compris toutes les exigences qu’ils doivent satisfaire.

les deux sont valables, selon les circonstances. La première solution est la meilleure lorsque les conditions suivantes sont remplies:

le nombre d'éléments à additionner est relativement petit
il y a peu ou pas de cas exceptionnels à prendre en compte (retours, ajustements, etc.)
la quantité d'article en stock n'est pas nécessaire très souvent

Par contre, si vous avez un grand nombre d’articles, plusieurs cas exceptionnels et un accès fréquent, il sera plus efficace de maintenir la quantité d’articles

Notez également que si votre système présente des divergences, il contient des bogues qui doivent être recherchés et éliminés

J'ai utilisé des systèmes dans les deux sens, et les deux peuvent très bien fonctionner - tant que vous n'ignorez pas les bugs!

Découvrez le modèle de données ARTS ( http://nrf-arts.org <). Il utilise une table StockLedger avec un enregistrement de chaque article et les modifications de l'inventaire sont toutes suivies dans InventoryJournalEntries.

Il est important de prendre en compte le système existant, ainsi que les coûts et les risques liés à sa modification. Je travaille avec une base de données qui stocke l'inventaire un peu comme le vôtre, mais elle inclut les cycles d'audit et les ajustements des magasins, comme les reçus. Cela semble bien fonctionner, mais toutes les personnes concernées sont bien formées et le personnel de l'entrepôt n'est pas très rapide à apprendre de nouvelles procédures.

Dans votre cas, si vous recherchez un suivi un peu plus important sans modifier la structure de la base de données, nous vous suggérons d'ajouter un tableau de suivi (un peu comme dans votre solution de "transaction"), puis de consigner les modifications dans l'inventaire. niveau. Il ne devrait pas être trop difficile de mettre à jour la plupart des modifications apportées au niveau de stock afin qu'elles laissent également un enregistrement de transaction. Vous pouvez également ajouter une tâche périodique pour sauvegarder le niveau d’inventaire dans la table des transactions toutes les deux heures environ, de sorte que même en cas d’absence d’une transaction, vous puissiez savoir quand le changement a eu lieu ou revenir à un état antérieur.

Si vous souhaitez voir comment une application volumineuse examine SugarCRM , ils disposent d'un inventaire. module de gestion si je ne suis pas sûr de la façon dont il stocke les données.

Je pense qu’il s’agit en fait d’une question générale sur les pratiques optimales, qui consiste à faire un compte (relativement) coûteux chaque fois que vous avez besoin d’un total, à le faire chaque fois que quelque chose change, puis en enregistrant le compte dans un champ et en le lisant à chaque fois. vous avez besoin d'un total.

Si je ne pouvais pas utiliser les transactions, j'utiliserais le décompte en direct chaque fois que j'en aurais besoin d'un total. Si des transactions sont disponibles, il serait prudent d'exécuter les opérations de mise à jour de l'inventaire et de sauvegarder le total recompté dans la même transaction, ce qui garantirait l'exactitude du comptage (bien que je ne sois pas sûr que cela fonctionnerait avec plusieurs utilisateurs. frapper la base de données).

Mais si les performances ne représentent pas vraiment un gros problème (et que les bases de données modernes permettent assez de compter les rangées et que cela m'inquiète rarement), je m'en tiendrai à chaque fois au décompte en direct.

Je choisirais le premier moyen, où

la quantité en main est calculée total des stocks reçus - total de inventaire vendu

La bonne façon, IMO.

MODIFIER: je souhaiterais également prendre en compte les pertes / dommages d’origine stock dans le système, mais je suis sûr que vous avez couvert cela.

J'ai déjà travaillé sur des systèmes permettant de résoudre ce problème. Je pense que la solution idéale est une colonne précalculée, qui vous procure le meilleur des deux mondes. Votre total serait un champ quelque part, donc pas de recherches coûteuses, mais il ne peut pas être désynchronisé avec le reste de vos données (la base de données préserve l'intégrité). Je ne me souviens pas quels RDMS prennent en charge les colonnes précalculées, mais si vous n'avez pas de transaction, cela risque de ne pas être disponible non plus.

Vous pourriez potentiellement simuler (très efficacement ... je ne vois aucun inconvénient) les colonnes précalculées en utilisant des déclencheurs. Cependant, vous aurez probablement besoin de transactions. IMHO, le maintien de l'intégrité des données lorsque vous effectuez ce type de dénormalisation contrôlée est la seule utilisation légitime d'un déclencheur.

Django-Inventory est davantage adapté aux immobilisations, mais peut vous en donner idées.

IE: ItemTemplate (class) - > ItemsOnHand (instance)

ItemsOnHand peut être lié à plusieurs ItemTemplates; Exemple d'imprimante & amp; les cartouches d'encre est requis. Cela permet également de définir des points de réorganisation pour chaque ItemOnHand.

Chaque ItemOnHand est lié à InventoryTransactions, ce qui facilite l’audit. Pour éviter de calculer les articles en main réels à partir de milliers de transactions invetory, des points de contrôle sont utilisés, lesquels sont juste un solde + une date. Pour calculer les éléments en main, recherchez le dernier point de contrôle et commencez à ajouter ou soustraire des éléments pour rechercher le solde actuel des éléments. Définissez périodiquement de nouveaux points de contrôle.

Je vois un avantage à avoir les deux colonnes, mais je ne suis pas la partie sur les divergences - vous semblez impliquer que le fait d'avoir les deux colonnes (entrées et sorties) est moins sujet à la divergence qu'une seule colonne ( actuel). Pourquoi est-ce?

N'a pas une ou deux colonnes, ce que je voulais dire par "total des stocks reçus - total des stocks vendus". est quelque chose comme ça:

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

puis

Qunatity_on_hand = inventory_received - inventory_sold

N'oubliez pas que j'ai trop simplifié ceci et mon explication initiale. Je sais que l'inventaire ne se limite pas à la gestion des quantités, mais dans ce cas, le problème réside dans ce que nous voulons résoudre. À ce stade, la raison de le changer est précisément le coût de la résolution des problèmes causés par la conception actuelle.

Je voulais aussi mentionner que bien que ce ne soit pas un "codage" La question est liée aux algorithmes et à la conception, qui sont des sujets très importants à mon humble avis.

Merci à tous pour vos réponses jusqu'à présent.

Nelson Marmol

Nous résolvons différents problèmes, mais notre approche de certains d’entre eux pourrait vous intéresser.

Nous permettons au système de "deviner", et donnons aux utilisateurs des retours réguliers sur toutes les suppositions erronées.

Pour appliquer cela à l'inventaire, vous pouvez avoir 3 champs:

inventory_received
inventory_sold
estimated_on_hand

Ensuite, vous pouvez exécuter un processus (quotidien?) dans le sens suivant:

SELECT * 
FROM   Inventory
WHERE  estimated_on_hand != inventory_received - inventory_sold

Bien sûr, cela dépend des utilisateurs qui consultent cette alerte et qui agissent.

De plus, vous pourriez avoir une fonction permettant de réinitialiser l’inventaire, soit en mettant à jour Inventory_sold / reçu, soit en ajoutant un autre champ "Inventory_adjustment", ce qui pourrait être positif ou négatif.

... juste quelques réflexions. J'espère que c'est utile.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow