Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
ça sert à rien ce champ. Dans ta table (via phpmyadmin) tu crée un index (via le menu structure-> index+) sur trois colonnes. Et ensuite tu choisi un nom, le type d'index (unique ou primaire), et tu sélectionne les colonnes correspondantes puis tu cliques sur ok.
Une fois cet index créé il devrait-être impossible d'insérer une nouvelle ligne (fais un test) qui possède ces même trois champs identiques dans une autre ligne.
J'ai créé l'index sur les 3 champs (clé unique car primaire, il me disait qui y en avait déjà une) et le test donne :ERREUR PDO dans C:\wamp\www\petit_site\action_patient.php L.46 : SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'test-test-2147483647' for key 'nom'
Et bien alors ça fonctionne correctement ! Maintenant tu pourrais si besoin utiliser on duplicate key update. Mais au passage et pour en être certain, c'est quoi ta clé primaire ?
Je comprends vraiment pas ta logique...
Tu nous parles de médecins et de leurs patients et tu soutiens que le numéro de sécu n'est pas utile ?
Quel genre de médecin n'a pas besoin du numéro de sécu de ses patients ?
Et en plus, cerise sur le gâteau, le numéro de sécu est le seul élément permettant d'avoir une clé unique ou primaire et ainsi créer une table à peu près digne de ce nom...
À ce niveau là, il ne s'agit plus de te convaincre... si tu ne le fais pas, ça confirme ce que je te disais dans un message précédent : tu n'as ni les connaissances ni les compétences pour faire cette appli.
Pas de question technique par MP !
Je viens de le faire :Envoyé par ABCIWEB
La clé primaire, avant, c'était `id_patient` (j'ai changé le nom : id_medecin -> id_patient) mais j'ai aussi changé la clé primaire (hier soir, je devais être trop fatigué pour y penser), donc maintenant, c'est "num_secu"...
Code php : Sélectionner tout - Visualiser dans une fenêtre à part $sql="INSERT INTO `patient` (nom,prenom,date_naissance,num_secu) VALUES (:nom,:prenom,:champ_date,:num_secu) on duplicate key update nom=:nom2,prenom=:prenom2,date_naissance=:champ_date2,num_secu=:num_secu2";
Donc oui, ça marche, sauf que s'il y a un doublon, l'insert n'est pas effectué, mais on est pas prévenu : y aurait-il moyen dans ce cas de mettre un message ?
Sinon, Bovino, ma logique (et les spécs des médecins), c'est de simplifier au max l'interface donc ne saisir le numéro de sécu que si nécessaire...
Désolé de te contredire, mais je crois que si...tu n'as ni les connaissances ni les compétences pour faire cette appli.
Attention si tu as une colonne de correspondance "id_medecin" dans cette table, il ne faudrait pas définir une clé unique avec seulement les trois colonnes "num_secu", "nom" et "prenom" car cela t'interdirais de rentrer deux fois le même patient - qui pourrait être à la fois patient d'un généraliste et patient d'un kiné dans un cabinet multi disciplinaire. Pour que cela puisse être possible il faudrait définir la clé unique avec ces quatre colonnes (incluant "id_medecin") .
Cela dit pour faciliter la saisie et éviter des éventuelles redondances dans ta table, il serait mieux de faire une table de correspondance "id_medecin -> id_patient" (dans une table distincte) et de ne garder que l'id_patient dans la table "patients".
Désolé mais je ne vois pas bien ce que serait cette table de correspondance "id_medecin -> id_patient". Cela dit, il y aura bien plusieurs disciplines de santé, qui se partagent le même patient (il est censé passer tour à tour de main en main), aussi ai-je prévu une table "patient" + une table "medecin" + une table "kine", etc. et chaque table de professionnel (medecin, kine, etc.) comporterait un champ "id_patient" qui permettra de faire le lien avec la table ""patient".
Bonjour Laurent,
j'espère que tu as BIEN REFLECHI à la CONCEPTION des tables.
D'abord, une TABLE "T_PATIENTS", contenant : les coordonnées du patient
id_patient (auto-incrément)
nom_patient
prenom_patient
...
En général, un patient a UN (et un seul) médecin de famille.
Par contre, il peut très bien consulter d'autres médecins, kinés, chirurgiens,...
De plus, on peut regrouper les "médecin", "kiné", "osthéo",....... sous le terme générique de "praticien".
Concernant les PRATICIENS, je ferais donc :
une TABLE "T_PRATICIENS", contenant : les coordonnées du praticien
id_praticien (auto-incrément)
id_praticiencat
nom_praticien
prenom_praticien
...
une TABLE "T_PRATICIENS_CAT", contenant la "catégorie" (discipline) : "médecin", "kiné", "osthéo",.......
id_praticiencat (auto-incrément)
nom_praticiencat
Concernant les RELATIONS entre PRATICIENS et PATIENTS, je ferais une TABLE relationnelle intermédiaire :
une TABLE "T_CONSULTATIONS"
id_consultation (auto-incrément)
id_praticien
id_patient
date_consultation
...
Bref : "concepteur de base de données" est un vrai Métier !
Et on ne commence pas à coder tant que la conception n'est pas clairement définie.
Dernière modification par Invité ; 12/12/2013 à 21h04.
Cette étude devrais même être faite pour l'établissement du devis, sinon comment tu calcules la durée de ton travail ? à la pageà la tête du client
... pour toi ... 3 jours par page
Ce que je voulais dire c'est que si tu as une table medecin de ce type
table medecin
id_medecin
nom
prenon
et une table patient
id_patient
nom
prenom
num_secu
Si un même patient peut avoir plusieurs médecins il faut faire une table de correspondance
id_medecin
id_patient
pour pouvoir affecter une même fiche (d'information générale) du patient à différents médecins.
Sinon - si l'id_medecin se trouvait dans la table "patients" -, la fiche générale du patient devra être re saisie pour chaque nouveau médecin que consultera le patient et produira des données redondantes inutiles dans ta table. Inutiles et pénibles à gérer car si par exemple tu enregistre l'adresse du patient et qu'elle à besoin d'être changée ultérieurement, il faudra la changer dans plusieurs lignes (correspondant aux différents médecins que consulte ce patient).
Mon cas est un peu particulier : chaque patient aura les mêmes médecins, car en fait, il s'agit que chaque professionnel de santé examine chacun des patients ; il s'agit de médecine du sport et chaque jeune sportif (sport-étude) doit subir un check-up par différents professionnels de santé. Donc le besoin, c'est d'établir des formulaires pour chaque professionnel, formulaire qui servira pour le check-up de chaque patient et bien sûr mémoriser les notes du professionnel dans une bdd. Et la spéc, c'est la simplicité, c'est-à-dire le moins de saisie possible, donc par exemple pour chaque question la réponse par défaut sera RAS et le professionnel ne modifiera la réponse que s'il y a quelque chose à signaler ; de même, pour chaque question, il y aura 2 cases à cocher "fait" et "non fait" et elles seront toutes initilalisées à "fait", sachant que c'est le but et sera le cas la plupart du temps. Le besoin sera aussi de pouvoir faire une première saisie puis de pouvoir la modifier ultérieurement.
Donc en gros, j'imagine une table "patient" avec sa carte d'identité (nom, prénom, date de naissance, numéro de sécu) et pour chaque professionnel de santé une table dans laquelle on mettra chaque consultation (date, id_patient, et pour chaque réponse un champ réponse et un champ fait-non fait). Par contre, vu que la correspondance sera la même pour tous, je ne ressens pas le besoin d'une table de correspondance. Est-ce que ce que j'ai imaginé tient la route ?
Il ne suffit pas d'"imaginer" !
Rédige clairement la structure de chacune des TABLEs.
On verra si ca tient la route.
Voilà comment je vois la conception des tables :
patient
-------
id_patient : int (8)auto-increment
nom : varchar (20)
prenom : varchar (15)
date_naissance : varchar (30)
num_secu : bigint(15)
La date de naissance est saisie avec datepicker duquel je récupère 3 infos (DD, MM, YY) et je les concatène en une chaîne de caractères (je l'avais déjà fait antérieurement, c'est au point)
et pour les différentes tables des professionnels (donc enregistrement des consultations par chaque professionnel) :
praticien
---------
id_praticien : int (8) auto-increment
nom_patient : varchar(36) (concaténation nom-prénom)
date_consultation : varchar (30)
question1 : varchar(15)
fait1 : BOOL
question2 : varchar(15)
fait2 : BOOL
...
Même si elle n'est pas indispensable dans ce cas, au cas où elle le deviendrait pour des besoins futurs (non encore prévus) cela ferait un gros bin's pour tout refaire. Alors que si tu adopte la façon standard avec une table de correspondance, ton code est évolutif dès le départ.
Il pourrait par exemple, dans un temps futur, exister des options sportives qui nécessitent des examens spécifiques (réalisés par un médecin spécialisé dans ce domaine et qui n'intervient pas dans d'autres domaines).
Il vaut mieux voir large et évolutif quand on conçoit un shéma de bdd.
Passons pour le RAS cela peut se comprendre par contre les cases concernant la vérification "fait" ou "non fait" cochées par défaut à "fait" c'est pour le moins irresponsable concernant un examen de santé
Ce que tu pourrais faire c'est cocher toutes les cases à "non fait" par défaut et proposer un bouton pour cocher automatiquement toutes les questions à "fait", ce qui imposerait au moins une intervention humaine avant d'envoyer le formulaire.
Tu parle de consultations et tu appelles la table "praticien" ?
A part cela, dans la table consultation, l'id_patient serait mieux venu que l'exotique (et faux pour les mêmes raisons déjà évoquées précédemment) champ varchar qui concatène non-prémon.
Et question toute bête chaque question ne pourra pas dépasser 15 caractères ? Et ton système fonctionne comment si tu dois rajouter une question, tu rajoute une colonne ?
Et comme tu n'es plus débutant, tu devrais savoir qu'un champ date se formate avec le format DATE et non varchar (aucune excuse n'est admissible pour ne pas faire ça correctement et ça concerne les deux tables que tu nous montre dans ton dernier message).
Je t'ai répondu sur d'autres points dans mon précédent message.
Il serait important que tu nous montre tes autres tables (avec quelques explications) avant d'aller plus loin. Pour l'instant c'est très confus. Ce serait peut-être l'occasion d'ouvrir un nouveau topic car cela n'a plus grand chose à voir avec la question initiale.
Le nom approprié serait "consultation_par_praticien" mais c'est un peu long...(sachant que chaque praticien devant réaliser des consultations, il y aura une table par praticien)
Merci pour cette remarque ; je remplace nom_patient par id_patient...
Si, 15, c'est juste pour l'exemple...
Ben oui ; la table aura pour nombre de colonnes le nombre max de questions (mais dans l'exemple papier qu'ils m'ont fourni, il n'y a qu'une seule réponse possible pour chaque point)
Je sais bien, mais la date, d'abord, je la saisie avec Datepicker, ce qui me fournit 3 infos (DD, MM et YY), puis je concatène les 3 pour faire une seule chaîne de caractères (donc une seule colonne dans la table mais bien de type varchar)
OK
Et qu'est-ce qui t'empêche de concaténer la chaine au format DATE de mysql avant de l'enregistrer en bdd ?
C'est un point essentiel et indispensable pour pouvoir faire ensuite des recherches sur les dates avec mysql. Tu ne peux pas te permettre d'être approximatif sur ce point.
OK, je prends en compte.
Et donc si on te demande de rajouter une question dans six mois, faudra tout refaire ton code ? Il y a un gros pb de conception là.
Ta remarque est juste et me mets la pression : elle rallonge le délai où je pourrai fournir quelque chose...
Répondre avec citation
Partager