Des dossiers médicaux
Fermé
abdoulayecoumba
-
7 déc. 2015 à 12:03
heliconius Messages postés 545 Date d'inscription mardi 1 juillet 2008 Statut Membre Dernière intervention 23 juin 2023 - 14 déc. 2015 à 01:08
heliconius Messages postés 545 Date d'inscription mardi 1 juillet 2008 Statut Membre Dernière intervention 23 juin 2023 - 14 déc. 2015 à 01:08
A voir également:
- Des dossiers médicaux
- Afficher la taille des dossiers - Guide
- Afficher les dossiers cachés - Guide
- Wetransfer envoyer des dossiers gratuit - Guide
- Sélectionnez une application qui permet d’accéder aux dossiers et fichiers d’un ordinateur. - Guide
- Télécharger logiciels médicaux gratuits - Télécharger - Organisation
4 réponses
jee pee
Messages postés
39659
Date d'inscription
mercredi 2 mai 2007
Statut
Modérateur
Dernière intervention
28 avril 2024
9 240
7 déc. 2015 à 12:33
7 déc. 2015 à 12:33
Bonjour,
Ce n'est pas ainsi qu'il faut raisonner. Dans une table on regroupe les éléments de même nature.
Pour ta problématique, une table patient, une table dossier médical et une table soins. Voilà les éléments de départ.
cdlt
Ce n'est pas ainsi qu'il faut raisonner. Dans une table on regroupe les éléments de même nature.
Pour ta problématique, une table patient, une table dossier médical et une table soins. Voilà les éléments de départ.
cdlt
jee pee
Messages postés
39659
Date d'inscription
mercredi 2 mai 2007
Statut
Modérateur
Dernière intervention
28 avril 2024
9 240
7 déc. 2015 à 17:02
7 déc. 2015 à 17:02
Avant de te lancer dans le développement, tu devrais suivre une formation initiale sur les bases de données. Tes questions mettent en avant que tu n'as pas les notions minimales sur la structure d'un sgbd.
Et une mauvaise conception de la structure, c'est la galère assurée dans le développement.
Et une mauvaise conception de la structure, c'est la galère assurée dans le développement.
A part que pour les consultations le patient ne passe pas une seule fois chez le médecin qui est l'utilisateur de la table .
Un patient peut visiter le Docteur plusieurs fois dans le mois ou l'année .
L'idée ici est de pouvoir donner au Médecin un outil de suivi de chaque l'individu- patient pendant plusieurs années .donc je pense que si je crée une table pour chaque personne ,chaque enregistrement pourra abriter les données relatives à chacune de ses consultations
Un patient peut visiter le Docteur plusieurs fois dans le mois ou l'année .
L'idée ici est de pouvoir donner au Médecin un outil de suivi de chaque l'individu- patient pendant plusieurs années .donc je pense que si je crée une table pour chaque personne ,chaque enregistrement pourra abriter les données relatives à chacune de ses consultations
heliconius
Messages postés
545
Date d'inscription
mardi 1 juillet 2008
Statut
Membre
Dernière intervention
23 juin 2023
137
14 déc. 2015 à 01:08
14 déc. 2015 à 01:08
"....donc je pense que si je crée une table pour..." :
Avant de connaître certaines choses on pense d'une façon, après les avoir connues, on pense d'une autre façon. On vient de te le dire avec justesse : il te manque quelques notions de base. Ce n'est pas un défaut, c'est seulement un manque que tu DOIS combler si tu veux poursuivre ton projet avec résultat. Au départ, on a tous eu des manques que l'on comble au fur et à mesure. Viens-tu ici chercher de l'aide ou viens-tu pour qu'on valide ta pensée ?
Si, comme te le suggère jee pee si tu as la possibilité de suivre une formation de base SGBD, saute dessus. Sinon cherche du côté de la méthode (d'analyse) Merise qui t'aidera à déterminer les tables dont tu as besoin et les liens qui existent entre elles. Si ta base de données est mal construite, non seulement c'est la galère assurée comme il t'a été dit mais les résultats produits par tes requêtes ne seront pas fiables.
Le meilleur conseil que je puisse te donner pour l'instant est de rédiger un texte (Word ou bloc-notes, peu importe) qui explique avec le plus de précision possible la manière dont s'effectue le travail de l'organisation pour laquelle tu fais cette application.
Ce qui se conçoit bien s'énonce clairement,
Et les mots pour le dire arrivent aisément.
(Boileau)
Si ton texte est clair (pour toi ou pour quelqu'un d'autre) et qu'il est validé par celui qui te demande cette application, c'est déjà que tu as bien compris la problématique et ce texte sera ta base de travail, ta référence, ton cahier des charges ; appelle ça comme tu veux.
Dans ce texte les mots t'orienteront vers les objets (de gestion) et les verbes vers les relations qui existent entre ces objets. Exemple: "Des clients achètent des produits pour lesquels on délivre une facture". "Clients", "Produits", "Factures" sont des objets de gestion (qui deviendront des tables) alors que "acheter" et "délivrer" traduisent les relations qui existent entre ces objets de gestion.
A priori tu auras les objets Médecins, patients, dossiers, visites (probablement des tables) et plus selon analyse ; reste à déterminer les relations qui deviendront des tables ou non selon le type de relation.
C'est beaucoup de "baratin", je sais, mais il est juste destiné à ce que tu réalises l'absolue nécessité d'une analyse, d'une réflexion avec des connaissances et des règles qui semblent bien te manquer pour l'instant. Ne pas te mettre à niveau, IMHO, c'est aller droit dans le mur.
Maintenant, tu poses une question, on te répond ; après, tu fais ce que tu veux de la réponse...
Avant de connaître certaines choses on pense d'une façon, après les avoir connues, on pense d'une autre façon. On vient de te le dire avec justesse : il te manque quelques notions de base. Ce n'est pas un défaut, c'est seulement un manque que tu DOIS combler si tu veux poursuivre ton projet avec résultat. Au départ, on a tous eu des manques que l'on comble au fur et à mesure. Viens-tu ici chercher de l'aide ou viens-tu pour qu'on valide ta pensée ?
Si, comme te le suggère jee pee si tu as la possibilité de suivre une formation de base SGBD, saute dessus. Sinon cherche du côté de la méthode (d'analyse) Merise qui t'aidera à déterminer les tables dont tu as besoin et les liens qui existent entre elles. Si ta base de données est mal construite, non seulement c'est la galère assurée comme il t'a été dit mais les résultats produits par tes requêtes ne seront pas fiables.
Le meilleur conseil que je puisse te donner pour l'instant est de rédiger un texte (Word ou bloc-notes, peu importe) qui explique avec le plus de précision possible la manière dont s'effectue le travail de l'organisation pour laquelle tu fais cette application.
Ce qui se conçoit bien s'énonce clairement,
Et les mots pour le dire arrivent aisément.
(Boileau)
Si ton texte est clair (pour toi ou pour quelqu'un d'autre) et qu'il est validé par celui qui te demande cette application, c'est déjà que tu as bien compris la problématique et ce texte sera ta base de travail, ta référence, ton cahier des charges ; appelle ça comme tu veux.
Dans ce texte les mots t'orienteront vers les objets (de gestion) et les verbes vers les relations qui existent entre ces objets. Exemple: "Des clients achètent des produits pour lesquels on délivre une facture". "Clients", "Produits", "Factures" sont des objets de gestion (qui deviendront des tables) alors que "acheter" et "délivrer" traduisent les relations qui existent entre ces objets de gestion.
A priori tu auras les objets Médecins, patients, dossiers, visites (probablement des tables) et plus selon analyse ; reste à déterminer les relations qui deviendront des tables ou non selon le type de relation.
C'est beaucoup de "baratin", je sais, mais il est juste destiné à ce que tu réalises l'absolue nécessité d'une analyse, d'une réflexion avec des connaissances et des règles qui semblent bien te manquer pour l'instant. Ne pas te mettre à niveau, IMHO, c'est aller droit dans le mur.
Maintenant, tu poses une question, on te répond ; après, tu fais ce que tu veux de la réponse...
