Discussion :

[laurentSc]

Bonjour,

je me suis attaqué à une application qui doit proposer à des médecins des formulaires pour des consultations, sachant qu'il doit être possible, non seulement de les remplir, mais aussi de les consulter ultérieurement.
La question majeure pour permettre l'évolutivité de l'application est de faire une conception correcte. ABCIWEB m'en avait proposé une qui m'a beaucoup plu :

consultations
id_consultation
id_praticien
id_patient
id_consultation_type (de la table consultation_type)
commentaire_consultation
date

consultation_type
id_consultation_type
titre_consultation_type
commentaire_consultation_type


questions
id_question
titre_question
question

consultation_type_question
id_consultation_type (de la table consultation_type)
id_question

consultation_resultat
id_consultation
id_question
commentaire_question (text) RAS par défaut
etat_question (bool pour fait/pas fait)

mais dans cette conception il faut rajouter 2 tables (patient et praticien). Je mets ici mon idée pour recueillir votre avis :

patient
nom_patient
prenom_patient
date_naissance
num_secu

et

praticien
id_praticien
nom_praticien
prenom_praticien
type_praticien (médecin, kiné, dentiste, etc)

(Il faut pouvoir distinguer le type de praticien sachant que pour chacun le formulaire de consultation sera différent).

Cela est-il correct ?

[mlebeguec]

Bonjour,

quelle est la clé primaire de la table patient ?

Ne pas oubliez que les enfants sont sous le numéro de sécu d'un des parents.

Natso.

[laurentSc]

Bonjour,

quelle est la clé primaire de la table patient ?

T'as raison ; j'ai oublié une ligne dans mon post :
patient
id_patient
nom_patient
prenom_patient
date_naissance
num_secu

Ne pas oubliez que les enfants sont sous le numéro de sécu d'un des parents.

Natso.

Oui, j'y pensais, d'où la colonne "date_naissance", comme ça, l'information existe, mais le champ "num_secu" me semble nécessaire au cas où 2 homonymes soit nés le même jour (cas très fréquent )

[mlebeguec]

Je n'ai pas fait le mcd de ton appli.

Mais s'il répond à toutes tes questions, tu peux commencer à écrire ton code.

Je créerai peut être une table type_praticien.

Bon courage

Natso

[laurentSc]

Oui, je la créerai si le besoin s'en fait ressentir...

Et pour "mcd", j'ai regardé sur Google (modèle conceptuel de données !)

[ABCIWEB]

Il faudrait trouver un moyen de relier la table praticien et la table consultation_type. Eventuellement tu pourrais mettre un champ "id_consultation_type" dans la table praticien. Ou si tu veux te servir du champ "type_praticien" il faudrait faire une table de correspondance entre "type_praticien" et "id_consultation_type", et dans ce cas créer aussi une table type_praticien pour gérer les catégories de médecins.

Sinon, si tu fais ni l'un ni l'autre, en plus de sélectionner son nom, le médecin devra sélectionner un type de consultation pour créer une consultation.

[laurentSc]

Oui, de toute façon, je la créerai (la table type_praticien), dès que le besoin s'en fera ressentir en codant (j'ai commencé hier, déjà 4 pages, mais je crois encore autant, et le plus difficile reste à faire...)(pour l'instant, je suis uniquement sur Wamp, mais quand ça sera au point, je le mettrai en ligne pour pouvoir le montrer (aux médecins...et ici))

[laurentSc]

Bonsoir,

j'ai un peu avancé dans la conception du site de médecine du sport, et je pense avoir une meilleure idée de la conception nécessaire pour les tables (légèrement modifié la proposition de ABCIWEB (mais je précise : c'est une première, et je m'attends à trouver encore des lacunes en continuant le développement)) :

patient :
id_patient : int (8)auto-increment
nom : varchar (20)
prenom : varchar (20)
date_naissance : date
num_secu : bigint(15)

praticien :

`id_praticien`: mediumint(8) AUTO_INCREMENT,
`nom_praticien`: varchar(20)
`prenom_praticien`: varchar(20)
`cat_praticien`: varchar(20)

consultation :
`id_consultation` : int (8)auto-increment
`id_praticien`: int (8)
`id_patient` : int (8)
`id_consultation_type`: int (8)
`commentaire_consultation` : varchar(20)
`date_consultation` : date

consultation_type :
`id_consultation_type` : int (8)
`titre_consultation_type` : varchar(20)

consultation_resultat :
`id_consultation_resultat` : mediumint(8) AUTO_INCREMENT,
`id_question`: mediumint(8)
`commentaire_question` : varchar(30)
`etat_question` : BOOL

consultation_type_question :
`id_consultation_type` : mediumint(8)
`id_question` : mediumint(8)

questions :
`id_question` : mediumint(8)
`question` : varchar(30)
`question_name` : varchar(20)
`liste_der` : varchar(20)
`liste_der_name` : varchar(20)

Voici l'état de mes réflexions ; j'affiche déjà un formulaire et enregistre une nouvelle consultation, mais pas encore les réponses aux questions, et pas encore capable d'afficher le formulaire déjà rempli d'un patient déjà examiné.

[ABCIWEB]

Le fait de mettre 'cat_praticien' directement dans la table praticien implique qu'un praticien ne peut avoir qu'une seule spécialité. Pour ne pas être limité il faudrait supprimer ce champ et faire une table de liaison entre praticien et catégories, par exemple
praticien_categorie
id_praticien (de la table praticien)
cat_praticien

Par ailleurs, ne devrais-tu pas faire une table de correspondance entre cat_praticien et consultation_type, par exemple :
cat_praticien_consultation_type
`cat_praticien`: varchar(20)
`id_consultation_type` : int (8) (de la table consultation_type)

Enfin bon difficile de te répondre avec le peu d'éléments qu'on a. Il faudrait que tu nous en dise plus sur la logique de l'application (avec des mots, pas avec du code).
Et je suis assez curieux d'avoir quelques explications sur les champs de la table questions.
Par ailleurs en plus d'explications sur le fonctionnement général il faudrait remplir quelques lignes de chaque table avec des exemples cohérents. Cette étape est indispensable pour bien saisir le mécanisme.

[laurentSc]

Merci de me répondre à une heure aussi avancée de la nuit !

OK de prendre en compte le cas d'un médecin qui serait aussi dentiste mais ça doit pas être fréquent...Pas sûr d'en tenir compte...

Sinon, la table de correspondance entre cat_praticien et consultation_type, comme je partais de l'hypothèse qu'un praticien avait une seule spécialité, donc un seul type de consultation, pour moi, la colonne "titre_consultation_type" de la table "consultation_type" correspond forcément à "cat_praticien" et donc je pense qu'avec mon hypothèse, la table est inutile...

Enfin, tu aurais souhaité des explications sur les champs de la table "questions" ; comme il s'agit du contenu d'un formulaire relatif à une question, les "x_name" sont les "name" de l'input (ou select) dans le formulaire et pour chaque question, il y aura une ou deux réponses à apporter : d'abord, un input de type "text" (question) et éventuellement, en plus une liste déroulante (un select)(liste_der) sauf qu'en pensant un peu à ça, je me dis qu'il faudrait un champ de plus, pour signifier s'il faudrait prendre en compte le champ "liste_der" ou non. (Comme je n'ai encore jamais conçu de table, je découvre les besoins au fur et à mesure, parfois en commençant le codage...)

Voilà, une partie des réponses ; la logique de l'application n'existe pas sous forme écrite (uniquement dans la tête) et remplir des exemples du contenu des tables, je n'ai pas fait cet exercice ; en fait, j'ai ma petite idée et je la teste (et éventuellement la corrige en codant).

[ABCIWEB]

Si une question peut être associée à une liste d'autres questions, il faut faire une table pour contenir ces listes. Si on appelle cette table "question_details"

question_details
'id_question' (de la table questions)
'question_item' (correspondant à chaque champ du select)

exemple de remplissage :
ligne 1
'id_question' : 5
'question_item' : une première valeur du select (pour la question 5)
ligne 2
'id_question' : 5
'question_item' : une seconde valeur du select (pour la question 5)
ligne 3
'id_question' : 5
'question_item' : une troisième valeur du select (pour la question 5)
ligne 4
'id_question' : 7
'question_item' : une première valeur du select (pour la question 7)
ligne 5
'id_question' : 7
'question_item' : une seconde valeur du select (pour la question 7)
etc.

Et si tu veux pouvoir lister tes sélect dans un ordre précis il faudrait un champ "ordre" dans ta table. Idem pour ta table question.

Et tout ça c'est pour créer et lister les questions. Il va falloir aussi faire des modifs (ajout de table si plusieurs réponses possibles pour les valeurs du select) pour enregistrer le résultat.

C'est étonnant que tu te lance dans un tel projet sans jamais avoir conçu de tables...
C'est quand même pas un projet pour débutant. C'est pareil que si tu te lançais dans la construction d'un immeuble avec uniquement quelques notions de bricolage et sans avoir jamais conçu la moindre cabane en bois. J'espère que tu n'as pas donné de délais...

Enfin toujours est-il que tu dois comprendre qu'on ne peut pas construire un schéma de table complet sans avoir un cahier des charges précis.

[laurentSc]

Je ne lis ta réponse que ce matin...

Pour les listes déroulantes, tu proposes une solution bien différente de ce que j'avais imaginé : une 2e table, et un enregistrement dans cette 2e table par item du select : y a pas moyen de s'en tirer avec une colonne de type ENUM ?

J'espère que tu n'as pas donné de délais...

Je ne me suis pas engagé, mais j'espère pondre un truc d'ici fin janvier.

Enfin toujours est-il que tu dois comprendre qu'on ne peut pas construire un schéma de table complet sans avoir un cahier des charges précis.

Je partais avec une idée de cette conception et de la corriger éventuellement si le besoin s'en fait sentir lors du codage ; penses-tu que c'est jouable ?

[ABCIWEB]

Je crois que tu n'as pas compris le principe du schéma des tables que je t'ai proposé.
La table questions est faite pour créer des questions, pas pour enregistrer les résultats. C'est la table consultation_resultat qui est prévue pour enregistrer les résultats.

Si tu veux pouvoir facilement gérer le contenu d'un select il vaut mieux créer une table pour cela. L'autre argument qui plaide en la faveur de la création de cette table est que tu dis que ce champ ne sera pas toujours utilisé dans ta table question.

Je partais avec une idée de cette conception et de la corriger éventuellement si le besoin s'en fait sentir lors du codage ; penses-tu que c'est jouable ?

Non pas de cette façon. En premier lieu il faut un cahier des charges et c'est en fonction de cela qu'on peut concevoir la logique de l'application, et ensuite concevoir le schéma des tables et puis enfin commencer à coder.

Tant que tu n'auras pas clairement donné avec un maximum de détails un exemple type de consultation (utilisation par le praticien de ton application tout au long de la consultation avec toutes les variantes et donc avec des exemples), je ne peux pas savoir si le schéma donné au départ est cohérent et/ou suffisant. Donc comment veux tu que je te réponde avec le peu d'éléments que tu nous donne ? Encore une fois il nous faut des détails !

Je ne me suis pas engagé, mais j'espère pondre un truc d'ici fin janvier

En restant aussi vague, je dirai que tu as bien fait de ne pas préciser l'année.

[laurentSc]

Je crois que tu n'as pas compris le principe du schéma des tables que je t'ai proposé.
La table questions est faite pour créer des questions, pas pour enregistrer les résultats. C'est la table consultation_resultat qui est prévue pour enregistrer les résultats.

Si, j'avais compris ça, et d'ailleurs, j'ai déjà codé l'affichage d'un formulaire (sans liste déroulante)

EDIT : qu'est-ce qui te fait penser que j'avais pas compris ?

Non pas de cette façon. En premier lieu il faut un cahier des charges et c'est en fonction de cela qu'on peut concevoir la logique de l'application, et ensuite concevoir le schéma des tables et puis enfin commencer à coder.

Tant que tu n'auras pas clairement donné avec un maximum de détails un exemple type de consultation (utilisation par le praticien de ton application tout au long de la consultation avec toutes les variantes et donc avec des exemples), je ne peux pas savoir si le schéma donné au départ est cohérent et/ou suffisant. Donc comment veux tu que je te réponde avec le peu d'éléments que tu nous donne ? Encore une fois il nous faut des détails !
.

Je m'y atèle et le montre ici quand ça sera fait.

En restant aussi vague, je dirai que tu as bien fait de ne pas préciser l'année.

Le plus tôt sera le mieux (en disant ça, je prends pas de risque)

[ABCIWEB]

Je m'y atèle et le montre ici quand ça sera fait.

Cela ne demande pas un travail de codage, et donc ne devrait pas prendre beaucoup de temps. C'est simplement l'explication simple, mais détaillée, avec des mots, et non pas avec du code, de d'utilisation de ton application par un praticien lors d'une consultation. Et il faut l'expliquer avec des exemples en mentionnant les variantes (un exemple avec une question simple, une autre avec l'utilisation d'un select... et plus s'il existe d'autres cas). C'est avec ça qu'on peut concevoir la fondation principale de la logique du code.
Le reste est plus secondaire car plus générique (les modifications de code seront moins importantes si besoin), mais la fondation principale nécessite un soin particulier sinon cela demandera de nombreuses et très laborieuses modifications en cas d'approximation/erreur de conception qui seront autant de limitations.

[Dendrite]

OK de prendre en compte le cas d'un médecin qui serait aussi dentiste mais ça doit pas être fréquent...Pas sûr d'en tenir compte...

Moi, je rebondis là-dessus.
Tu comptes faire une base de données, un truc souple qui va prendre toutes les données telles qu'elles sont et pas telles que tu aimerais qu'elles fussent.
Quand un cas un peu particulier se pointe, tu comptes dire quoi ? "Ah non, ça, ça rentre pas dans ma base de données pour cas simple(t)s."
Les bases de données professionnelles sont pleines de cas "pas fréquents".

[ABCIWEB]

EDIT : qu'est-ce qui te fait penser que j'avais pas compris ?

L'histoire du ENUM. Une colonne de ce type est faite pour accepter une des valeurs proposées lors de création la colonne, pas pour définir une multitude de valeurs...

[laurentSc]

3 réponses après 5h du matin...Mais faut dormir la nuit

Le cahier des charges, j'ai fait hier une première version à valider par les soignants avant de la montrer ici, mais j'ai pas mis d'exemple ; je vais donc l'enrichir...
Je prends aussi en compte la remarque de Dendrite, et enfin l'histoire du ENUM venait d'une confusion de ma part (j'ai pas l'habitude).

[laurentSc]

Moi, je rebondis là-dessus.
Tu comptes faire une base de données, un truc souple qui va prendre toutes les données telles qu'elles sont et pas telles que tu aimerais qu'elles fussent.
...
Les bases de données professionnelles sont pleines de cas "pas fréquents".

Je reviens là-dessus (et je pense aussi au cas où y aurait plusieurs praticiens dans le même spécialité (ce qui, je crois, est déjà le cas)) : la solution la plus évidente serait, dans les formulaires, de rajouter un champ où le praticien rentrerait son nom, mais comme le souhait est de faire un outil qui soit le plus rapide possible, voilà ce que j'envisage (pour éviter cette saisie supplémentaire) : dans le cas d'un praticien avec plusieurs spécialités ou dans le cas d'une spécialité avec plusieurs praticiens, on rajoute un enregistrement dans la table "praticien" :

nom----prenom----cat_praticien
nom----prenom----médecin
nom----prenom----dentiste

ou

nom1--prenom1--médecin
nom2--prenom2--médecin

et pour le cas de plusieurs praticiens ayant la même spécialité, chacun sa page (avec un titre explicite) et si un praticien a plusieurs spécialités, il aura plusieurs formulaires à remplir. (et donc, rien à changer dans la conception des tables).

[ABCIWEB]

C'est pas la peine de préciser que "le souhait est de faire un outil qui soit le plus rapide possible", car évidemment c'est toujours le cas

Le fait de rajouter une table praticien_categorie comme je l'ai indiqué plus haut ne crée pas une étape supplémentaire dans la saisie du formulaire. Niveau utilisateur c'est invisible, c'est juste au niveau de ton code que tu auras à faire deux insertions à la place d'une.

Et on ne remet pas en cause la structure évolutive d'une bdd juste pour avoir à écrire une ligne de code en moins !
Sur ce point là (la création d'une table praticien_categorie) tu ne devrais pas discuter. D'ailleurs même si l'équipe médicale te disais qu'un praticien ne peut avoir qu'une seule spécialité, il faudrait quand même la faire car cela ne coûte rien et permet de s'adapter à des cas particuliers non encore prévus. Cela fait partie du développement standard d'une bdd.

Il faut absolument de sortir de la tête l'idée d'essayer de faire le moins de tables possibles !

Dans ton exemple, cette partie là est cohérente :
nom1--prenom1--médecin
nom2--prenom2--médecin
nom3--prenom3--dentiste

mais celle qui précède (avec plusieurs fois le même nom pour pouvoir entrer différentes catégories) ne l'est pas.