PHP|Débutant :: Forums

tu veux créer une vue ??
sinon, tout simplement :
[code:php]
$table0 = mysql_query("SELECT * FROM personne WHERE nom='$nom' and prenom='$prenom'");
[/code]

a++

salut!
merci pour vos réponses.

Mais si je laisse l'idée de créer la vue, et que je veuille faire:
avoir le nom, prénom de la personne (table personne) avec les absences qu'elle a eu (table absence), les demandes qui la concernent (table demande) et les activités auxquelles elle a participé (table activite). Est-ce que je peux faire une requête comme ça:

mais le problème avec cette requête est qu'elle ne me renverrai rien s'il y a une seule des conditions qui n'est pas remplie, or moi je veux qu'elle me renvoie celles qui sont remplies (car le nom est forcément dans la table personne, c'est à partir d'une liste déroulante du contenu de cette table que l'on a choisi la personne à chercher).
Avec des "or" à la place des "AND" je ne vois pas trop ce que ça peut donner.

PS: j'avais mis * pour ne pour faire court ici, sinon je préciserai les champs dont j'ai besoin.

bonne matinée

Bonjour,

Y a du progrès avec ta jointure à gauche, tu es sur la bonne voie. Pour arriver à ton résultat il faut que la table à gauche de ta jointure contienne d'une manière certaine toutes les personnes, et les tables à droite celles où des personnes peuvent ne pas s'y trouver.

Pour ta requête il sera necessaire de corriger ta syntaxe comme suit

si tu veux ne pas recontrer d'erreur.

De plus pour ta clause where travaille sur tes clés primaires, cela suffit et évite de travailler sur x indexs autorisant les doublons par table.

Bonne continuation.

Dernière modification par Jc (16-07-2010 21:09:01)

Bonsoir,
après maintes essais, j'ai finalement affiché les informations en 3 fois? C'est à dire, les informations du profil et des absences dans un tableau, celles des projets sur lesquels l'acter a travaillé dans une 2nd, et les demandes le concernant dans un autre.
J'avais déjà implémenté cette solution, mais j'ai voulu tout affiché ensemble.

merci pour vos interventions et vos conseils.

bye!

Bonjour,

Visiblement tu as mal compris, pour t'aider d'une manière efficace, si tu pouvais me donner la structure de tes 3 tables et me donner les informations que tu désires afficher dans l'ensemble. Il est important aussi que sur les colonnes que tu désires afficher dans ta requête contenant les 3 tables, que tu me dises pour chaque colonne si elle accepte une valeur NULL par défaut.

Je te sens pas mal perdue, mais sans ces infos, je ne pourrais rien faire de plus.

A bientôt de te lire.

Bonjour et merci,

Je regarde tout ca et je reviens vers toi dans la journée, je dois m'absenter cette fin de matinée.

Bonjour,

Me revoila

Donc à propos de ton soucis, il y a plein de choses à dire, tu t'en doutes.

1) STRUCTURE DE TES TABLES

a) Concernant les tables abscences, activites et demande
l'id de chaque table n'est pas associée à l'id d'une personne. Du coup il est possible d'enregistrer des enregistrements orphelins pour chaque table. Il me paraît donc nécessaire pour chacune de ces table de définir une clé primaire à la fois sur leur id respective et sur l'id d'une personne. Tu peux aussi pour te faciliter la gestion de tes enregistrements, définir l'id de chaque table en auto_incrément. Ces tables étant censées être des tables de jonction, il te faudra donc pour tes jointures externes, définir obligatoirement un index à doublons sur le champ id personne de ta clé primaire.
Note secondaire: Pense dans la mesure du possible pour optimiser les performances de tes tables ainsi que pour la récupération de données en cas de crash DD, de définir des tables statiques autant que possible, et si ce n'est pas possible, essayer de limiter au maximum les champs de taille variable au sein de tes tables. Par ex, un numéro de tel n'a pas besoin d'un champ de type  VARCHAR, mettre un id au format numérique et si il est alphanumérique définir un peigne de codification sur une taille fixe ex : id="ABS" ou id="RJCT" et donc défini en type CHAR, quitte à faire une table qui liste les codes et les commente (2 champs), ce qui t'offrira de plus, beaucoup plus de souplesse dans la gestion de ton applicatif.
PS: Même un champ Password peut être défini en CHAR: Pour assurer à la fois la confidentialité des passwords utilisateur et la sécurité applicative, l'idéal est de définir un password en CHAR(40) et de l'encoder en SHA1 qui code en longueur fixe à 40 caractères.

b) La table Absences.
Il te faut un index sur datedebut et datefin. Je te conseille niveau performances de definir datedébut en timestamp avec en valeur par défaut current_timestamp. Du coup l'info datedebut sera automatiquement insérée à la création d'un enregistrement.

c) La table activite
Je ne suis pas certain en l'etat actuel des infos en ma possession que les indexs défini sur cette table soient necessaires dans leur ensemble.

2) CREATION DES VUES
Ton choix d'afficher les informations sur les trois tableaux cités dans ton dernier post me paraît le plus performant et le plus rationnel dans le cadre d'un applicatif de gestion de ces informations.
Par contre, dans l'etat actuel des choses, il te manque ta requête principale pour établir ton tableau de bord sur les personnes.
Une fois les modifications structurelles necessaires effectuées (celles du a)), il te sera possible de la réaliser. Voici les informations que je te propose d'y mettre:
1) Nom, prénom de la personne
2) actuellement en absence ou non
3) nombre d'absences par période de temps à définir (par ex: l'année en cours)
4) Nombre de demandes faites (sur l'année en cours par ex)
5) Nombre de demandes en cours de traitement
6) Nombre de Projets de travail en cours
7) Nombre de Projets de travail auquel la personne à participer sur l'année en cours par ex.

Si tu as besoin d'autres informations n'hésite pas à demander

++

Bonjour,

En ce qui concerne la table absence, je n'ai pas vu de champ id personne^^. Vu qu'une absence est toujours liée à une personne, je pense que tu pourras appliquer la clé primaire aux deux champs id sur cette table.
Sur ce point sur les tables activite et demande, le fait que id_acteur peut être nulle, n'est pas trop rationel, car elle est toujours initiée par quelqu'un^^ même si c'est un adm ou autre. C'est important que tu le fasses à mon humble avis, quitte à rajouter une table qui codifie les personnes avec un champ supplémentaire indexé dans la table personne correspondant au type de personne ex:ADM (administrateur), ELE (Eleve)... etc. De cette manière tu as un tri supplémentaire sur ta base de données personne, et ca te permet de gérer tes tables de jonction comme il se doit.

Note concernant les données statiques: Dans le cas de figure ou cela ne pose pas de problème il peut être préférable de scinder une table en deux avec d'un coté les infos statiques et de l'autre les infos dynamiques. Mais il faut ne pas prendre à la légère ce genre d'optimisation et considérer l'ensemble de la base de données et l'applicatif par lui même avant ce type de mise en oeuvre.

Dernière modification par Jc (21-07-2010 16:20:08)