Discussion :

[Efxc1973]

Bonjour,

Je suis en train de créer un programme de gestion de stock de matériel remis à des patients, certains sont connu, d'autres sont des patients sans nom.

Actuellement j'ai créé 3 tables

1. Table patient : Nom, prénom....
2. Table mouvement : id patient, date opération, id produit, désignation produit, libelle de l'opération, entrée, sortie
3. Table produit : référence produit, non produit, stock initial, entrée, sortie, stock final

Comment saisir les mouvements d'entées et de sorties des produit, lorsque le patient n'est pas connu ? création d'une nouvelle table ??

Merci de votre aide

[micniv]

Comment saisir les mouvements d'entées et de sorties des produit, lorsque le patient n'est pas connu ?

Le plus simple : tu crées un nom de patient bidon ...

[Clancy]

Je rejoins micniv sur l'idée d'un patient bidon, style "autre transaction", "indisponible".
Mais en réalité cela dépend de ton objectif, juste gérer les patients ou gérer en entier les stocks ?
Dans le deuxième cas il vaut mieux prévoir une deuxième table pour les non-patients, tu dois avoir des fournisseurs différents et des prises en charge pour calibration, entretien etc différents aussi.
Et administrativement parlant il faudra tout de même justifier tes sorties. Donc dans le premier cas il faudra bien penser à indiquer en libellé la ref de transaction correspondante dans un autre fichier de stock fournisseur et autres pour le "patient" "indisponible"

[loufab]

Bonjour,

Pas du tout d'accord avec Clancy.

Un patient sans nom reste un patient qui fait partie de l'entité patient.
Si tu crées une autre table pour les non patient, tu fais comment pour les clef externe patient ?
Tu crée une deuxième colonne pour déterminer si c'est un patient ou un non patient ?
Tu crée des relations multiples pour afficher les 2 types de patients ?

Autant utiliser la même table et créer un patient nommé "non-patient, John Doo, sans nom...". Et même si ce non-patient est un vrai patient juste sans le nom.
Dans tous les cas, continuer à utiliser la même table pour ne pas créer une Usine A Gaz difficile à maintenir où ma moindre évol va devenir chronophage.

Il est toujours plus simple de filtrer une table que d'en alterner 2.

Cordialement,

[Clancy]

Ben techniquement c'est que j'ai dis en intro de msg...
Pour le reste j'ai juste précisé l'obligation légale lors de l'établissement d'une facture de la mention du nom du client, ce qui implique d'avoir besoin des autres données.
D'où je réitère :
cela dépend si c'est juste un suivi des présences du matériel en question dans le stock
Ou
Si c'est pour de la gestion de stocks réelle qui va impliquer toutes les entrées et sorties du matériel.

[loufab]

En effet je n'ai pas dit le contraire . Je ne suis simplement pas d'accord avec ta 2ème proposition. C'est ce que j'indique dans mon message.

la table mouvement indique qu'il s'agit bien d'une gestion de type IO et pas d'un type état de stock.
La table Patient n'a pas d'incidence sur le type état de stock puisque ce n'est qu'un état quantitatif.
Cela n'a pas non plus d'incidence sur le modèle IO, du moment que la table mouvement identifie l'émetteur du mouvement.
Il n'est pas fait mention d'un quelconque besoin en matière de facturation.

La seule table qui pourrait être envisagée dans sur un branche parallèle à Patient serait Fournisseur.

Cordialement,

[binarygirl]

Je pense qu'on manque de contexte.
Pourquoi les patients ne sont pas connus ? Est-ce parce que les médecins/soignants embarquent une dotation de matériel avec eux, mais ne savent pas à l'avance à qui il sera destiné ? Une autre raison ?

En quoi est-ce important de lier les produits à un patient ? Est-ce pour facturer la prestation ? Dans ce cas, on n'est plus dans la simple gestion d'inventaire, il y a un aspect facturation également.
Sinon, on pourrait tout aussi bien assigner le matériel à un intervenant médical plutôt. C'est un autre cas d'utilisation possible, mais il faut savoir quel est le but de ce modèle de données.

On peut effectivement utiliser des noms bidon, ou tout simplement laisser le champ à NULL, dans ce cas évidemment le join avec la table patient ne pourra pas toujours se faire. Mais ce n'est pas interdit de faire cela. On peut ainsi comptabiliser un mouvement dans l'inventaire, sans forcément l'imputer avec précision. Tout dépend du degré de traçabilité que l'on veut en final.