Conception de base de données d'inventaire

Question

J'ai trouvé plusieurs exemples d'une base de données d'inventaire. Mais je cherche un peu différent. Je travaille avec SQL.

J'ai besoin de suivre l'outillage. Les employés peuvent vérifier l'outillage et l'inventaire de cet outil sera réduit et cette transaction sera enregistrée dans une table (checked_out). Facile à loin. Lorsque l'employé retourne l'outil ou les outils, l'employé a le choix.

Il peut soit renvoyer l'outil à l'inventaire. Encore assez facile. Ou il pourrait ramener l'outil cassé et le jeter, en d'autres termes l'enregistrer à la table à ordures. Ou il pourrait mettre l'outil dans le bac de réaffûtage et l'enregistrer sur la table de réaffûtage. C'est là que je suis confus.

Answer 1

Il semble que vous ayez besoin d'un statut dans la table d'inventaire. Par exemple, un enregistrement pour un outil arbitraire peut avoir un champ d'état qui est une clé étrangère dans le tableau "Statuts". Le tableau pourrait Statuses ressembler à ceci:

ID  Description 
----------------------- 
1  Available 
2  In Use 
3  Broken 

... etc.

Votre table d'inventaire pourrait ressembler à ceci:

id  status_id  description 
------------------------------------- 
1  2   Hammer 
2  1   Hammer 
3  3   Hammer 
4  1   Saw 
5  3   Saw 

Ensuite, lorsque vous calculez l'inventaire, seuls les enregistrements de GÉOLOCALISEZ un outil a le statut "1" pour Disponible. Vous pouvez également exécuter des requêtes pour la gestion afin de montrer combien d'outils sont "Broken". Prévoyez de supprimer éventuellement ces enregistrements une fois que les outils cassés auront été correctement comptabilisés ou gardez-les à des fins de données historiques.

À tout prix, évitez de créer des tables séparées pour la disposition d'une entité dans la base de données. Utilisez un champ "flag" (c'est-à-dire status_id), de sorte que vous pouvez ajouter de nouveaux statuts à une application sans avoir besoin d'ajouter de nouvelles tables à l'infini.

Answer 2

Votre configuration est mauvaise, vous ne devriez pas avoir une table séparée pour poubelle, check-out et -bin A aiguiser. Ce ne sont que des états que l'outil peut être trouvé.

Ce que vous voulez est une base de données qui inclut ces 2 tables qui abriteront les données proposées par hardcode dans his solution:

Inventory 
----- 
id (PK) 
description 
status_id (FK -> Statuses) 

Statuses 
---------- 
id (PK) 

Answer 3

J'aime le schéma de hardcode, mais il pourrait être un match plus proche de la situation en cours de modélisation pour stocker un emplacement au lieu d'un statut (dans tous les cas je déconseillerais l'utilisation du mot "status" qui est si générique pour être sans valeur). L'emplacement est vraiment ce qui est suivi ici, et pourrait même être utilisé pour indiquer qui est le détenteur actuel de l'article quand il est extrait. Je pense que la condition physique devrait être tenue séparément, si elle doit être suivie du tout. Cela permettrait d'obtenir des notes plus fines en fonction des commentaires des utilisateurs de l'outil ou de l'observation du personnel.

(En réponse aux commentaires 2)

j'attendre à ce que vous auriez une table pour enregistrer les mouvements individuels d'outils (de l'emplacement A à l'emplacement B à un certain moment par personne Z) et un autre à enregistrer un résumé de niveau supérieur ou l'emplacement actuel. Beaucoup dépendrait de savoir si les outils étaient identifiés individuellement par numéro de série, auquel cas vous les suivriez individuellement, ou s'il s'agissait simplement d'un numéro du même outil, non identifié individuellement. Cela déterminerait si vous enregistreriez 5 transactions (une pour chaque outil) ou 1 transaction de 5 outils.Vous pourriez résumer comme "5 outils extraits" ou vous pourriez indiquer "ces outils individuels sont actuellement à ces endroits".