insert si vide et update sinon

Laurent,
manifestement, c'est le TEMPS qui te pose le plus de problème, non ?

Le 1er problème étant que TU ne prends pas le TEMPS :

• de lire les tutos, d'apprendre et de retenir,
• de faire des recherche préalables avant de poster sur DVP,
• de réfléchir et d'étudier en profondeur,
• de trouver toi-même des réponses (à des questions simples, voire parfois simplistes),
• (dans le cas présent) de concevoir correctement.

Le 2ème étant que NOUS (DVPistes, bénévoles et altruistes) prenions sur NOTRE TEMPS pour :

• réfléchir et concevoir à ta place,
• trouver TES erreurs (que tu n'as pas le temps de déboguer toi-même),
• résoudre TES problèmes et écrire le code (toujours à ta place).

Enfin, TU NE prend PAS forcément le TEMPS de lire en détail les conseils, ou de prendre en compte les corrections qu'on te fourni...

Ca ne pose "pas trop" de problèmes, tant qu'ON a du TEMPS à te consacrer...
A toi de nous convaincre que NOUS ne perdons pas notre TEMPS.

Citation:

---

Envoyé par laurentSc

...elle rallonge le délai où je pourrai fournir quelque chose...

---

Le TEMPS que tu consacreras à la BONNE CONCEPTION de tes TABLEs N'EST PAS du TEMPS PERDU.
Bien au contraire !

Ca, il faut vraiment t'en convaincre !

Citation:

---

Envoyé par laurentSc

Ta remarque est juste et me mets la pression : elle rallonge le délai où je pourrai fournir quelque chose...

---

Oui enfin si on devait attendre d'avoir toutes les données avant de commencer à coder, comment ferait-on pour coder un forum ? :mrgreen:

Il me semble qu'on a déjà évoqué les tables de correspondance...

Faut sortir les questions de ta table "consultations", créer une table "questions", et si on veut faire des consultations type (regroupant plusieurs questions) il faut aussi faire une table de correspondance entre "consultation_type" et "questions"
Genre :

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)


Bon j'ai fais cela à la va vite (c'est pas nécessairement le mieux), mais c'est pour le principe. Il faut que tu comprenne le principe avant d'aller plus loin et comme dit jreaux62 prends le temps qu'il faut pour bien concevoir tes tables sinon tu courre à la cata.

Citation:

---

Envoyé par ABCIWEB

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é :aie:
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.

---

J'ai posé la question aux professionnels de santé et voici la réponse de l'un d'eux :

Citation:

---

Je persisterais sur la base du "fait" coché d'emblée, le gain de temps en saisie est le plus important en pratique s'il y avait un bouton pour cocher fait comme suggéré, moi c'est ce que je ferais en premier puis ensuite je noterais ce que je n'ai pas fait. Donc autant le laisser par défaut en coché fait.

---

:merci: ABCIWEB de me proposer une conception des tables ; j'avais pas vu quand j'ai mis mon post juste avant ; je vais étudier ça...

J'étais loin du compte et je ne risquais pas de concevoir ça...Je crois comprendre. Je prendrai des exemples pour bien assimiler tout ça, mais demain, car dodo (tôt aujourd'hui)

Je viens de commencer le codage avec ta conception des tables, ABCIWEB et notamment, j'ai pris en compte cette remarque :

Citation:

---

tu devrais savoir qu'un champ date se formate avec le format DATE et non varchar

---

Je le savais et en plus, j'ai déjà la fonction qui met la date dans le bon format :

Code:

---

1 2 3 4 5 6 7

function setFrenchDate($date) { $dateintermediaire=date_parse_from_format("d/m/Y",$date); //strptime marche pas $day=$dateintermediaire['day']; $month=$dateintermediaire['month']; $year=$dateintermediaire['year']; return($year."-".$month."-".$day);//conversion fr->ISO (format bdd) }

---

et pour ne pas mettre 2 fois le même patient dans la bdd, je fais :

Code:

---

$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";

---

c'est correct ? (sachant que la clé primaire est id_patient)

C'est la première fois que je vois cette fonction "date_parse_from_format"... Habituellement on fait plus court en utilisant date_create_from_format, ce qui pourrait donner :

Code:

---

1 2 3 4 5 6 7

function setSqlDateFromFormat($date,$format='d/m/Y') { $newdate = date_create_from_format($format,$date); return date_format($newdate, 'Y-m-d'); }   $french_date = '14/12/2013'; echo setSqlDateFromFormat($french_date);

---

C'est juste pour te montrer plus simple mais ta fonction semblait ok.

Concernant on duplicate key update, attention de l'utiliser à bon escient et uniquement si besoin. On ne l'utilise pas pour éviter de faire une duplication, on l'utilise pour avoir un code de requête commun entre un insert et un update. Mais dans ton contexte il faut bien entendu savoir si on fait un update ou un insert et une requête initiale de type select comme dans ton premier message (mais correctement réalisée ce qui n'était pas le cas) est la façon la plus habituelle de faire.

OK pour la gestion de la date, mais je l'ai déjà testée...

Sinon, t'as raison, en y réfléchissant, je pensais éviter la duplication comme tu le dis, mais qu'est-ce qu'elles ont de pas corrects mes requêtes du post #1 ?

Ta première requête "SELECT * from patient WHERE..." sélectionne tous les champs de la ligne et tu ne t'en sert pas donc autant ne pas les sélectionner. Et au cas où tu aurais eu besoin des valeurs des champs, le nombre de lignes retournées est donné (avec mysql) avec rowCount() et pas columnCount().

Cela dit, quand on fait une requête spécifiquement pour compter un nombre de lignes on utilise count par ex:

Code:

---

1 2 3

$sql = "SELECT COUNT(*) FROM fruit WHERE calories > 100"; $res = $conn->query($sql); $nb = $res->fetchColumn();

---

OK, et merci pour les explications. rowCount() , je l'avais déjà trouvé, mais exact, faire une requête qui fait juste ça, c'est encore mieux...

Une question sur les tables : pour les tables de correspondance, je ne mets pas de auto_increment ; correct ?

Autre question : pour la table consultation_resultat, il ne manque une colonne auto_increment id_consultation_resultat ?

Pourquoi faire ?
A priori il n'y en a pas besoin. C'est en faisant tes requêtes pour créer une consultation type (regroupant plusieurs questions) et ensuite pour enregistrer le résultat d'une consultation, que tu pourras te rendre compte si le schéma est fonctionnel et s'il te manque des champs, ou des tables.
Mais encore une fois, j'ai fais ce schéma de principe d'après les éléments que tu as donnés et s'il manque des éléments ou si j'ai mal compris, il peut être à refaire entièrement ou à compléter. Cela dit c'est une base qui permet de travailler les requêtes et les jointures et dans tous les cas tu auras besoin de travailler sur des schémas similaires donc tu ne perd pas ton temps à faire l'exercice.