comment faire ma relation ??Résolu

Question

Bonjour,

dans le cadre d'un projet informatique, je voudrais mettre en place une appli web en php/mysql permettant de gérer le stock de consommable de l 'entreprise ou je travaille.
J'ai décomposer ma bdd en 3 tables : utilisateur, printers(regroupant imprimantes, copieurs et fax), et type_cons(regroupant les différents types de consommables,leurs références et leur quantité disponible).
Ma question est donc la suivante: comme pour une imprimantes on peut avoir plusieurs types de consommables (Exemple: pour une imprimante, j'ai un toner noir de référence .... et de quantité ..., j'ai aussi un toner cyan de ref ... et de quantité ... , un toner magenta .... etc bref vous avez compris ou je voulais en venir ;-))J'en arrive à ma question, je voudrais regrouper dans un tableau la marque et modele de mon imprimante puis ds ce meme tableau tout les consommables associés à cette imprimantes ainsi que leur quantités, mais étant en phase d'apprentissage de PHP/MySQL, je ne sais pas trop comment arriver à réunir toutes ces informations dans un tableau unique, je ne comprends pas comment rélier ces 2 tables meme avec des jointures.
Voila si quelqu'un aurait la bonté de m'aiguiller sa serait très aimable de ca part.
Sur ceux bonsoir les artistes !!

kohntark · Accepted Answer

Salut,

Un peu en vrac :
champs utilisateur :
    - id (un identifiant unique dans ta table)
    - printer_id (correspond au champ id de la table printers que possède l'utilisateur)
    - name
    - first_name
    - ...

champs printers :
    - id (un identifiant unique dans ta table)
    - trademark (canon, lexmark, ...)
    - model (modèle de l'imprimante)
    - ...
   
champs type_cons :
    - id (un identifiant unique dans ta table)
    - model (sur ce champ tu feras la liaison avec le champ model de la table printers)
    - type_cons (type de consommable)
    - color
    - ...

// pour l'utilisateur "id utilisateur"
$user_id = '[ton id utilisateur]';
$sql = "
SELECT type_cons.type_cons, printers.trademark, printers.model, utilisateur.name, utilisateur.first_name
FROM utilisateur, printers, type_consWHERE utilisateur.printer.id printers.id AND type_cons.model printers.model
AND utilisateur.id = '$user_id'
";if (false $q mysql_query($sql)) die (mysql_error());

while ($r = mysql_fetch_array($q)) {
    // construction du tableau
}

Il y a peut être quelques erreurs qui se sont glissées par ci par là, je n'ai pas contrôlé et je n'ai pas testé.

Tiens nous au courant,

Kohntark-

malalam · Answer

Hello,

je ne suis pas d'accord : une imprimante accepte plusieurs types de consommable...mais un type de consommable peut aussi fonctionner sur plusieurs imprimantes.
La relation est de type n-n.
Il faut donc une table de jointure avec printer_id et consom_id.
Et à priori, idem pour les utilisateurs et les imprimantes. Il n'y a pas de raison pour qu'un utilisateur n'ait forcément qu'une seule imprimante.

krustypop · Answer

Salut et merci de votre participation ^^
je ne suis pas d'accord avec toi car un type de consommable possède une référence et ne peut être utiliser que pour un seul modèle d'imprimante.
Es-u d'accord ?

malalam · Answer

Ben non :-)
Un de mes clients est un GROS du matériel et des consommables d'impression, et je peux t'assurer que la plupart de leurs cartouches (sans parler de leurs papiers) peuvent fonctionner sur plusieurs modèles d'imprimantes (modèles proches certes, mais étant des références différentes néanmoins).
Après, si tu es certain que dans TON parc, cela n'arrivera pas, tu peux utiliser une relation 1-n en effet. Mais dans tous les cas, je ferais la jointure sur un id, pas sur la référence : c'est toujours plus rapide avec un entier qu'avec un champ de type chaîne.

krustypop · Answer

Merci de ton aide, par contre je ne comprends pas pourquoi il y a utilisateur dans la jointure, en fait ma table utilisateur sert juste à faire une authentification, pour sécuriser un minimum le site.
et merci encore je vais tester ce système

malalam · Answer

Oh chais pas, j'ai suivi kohntark (t'aurais pas pu faire plus simple comme pseudo? Je m'y suis repris à 3 fois!!) qui a associé une imprimante à un utilisateur, ce qui pouvait sembler logique. Si aucun rapport, alors oublie.

krustypop · Answer

oui c'est vrai que c'est logique je m'en servirai peut être par la suite !!
merci

krustypop · Answer

J'ai une autre question,(désolé ^^) j'utilise easyphp et donc phpmyadmin pour la bdd. Est ce que le simple faite de mettre le champ model dans la table type_cons va me faire ma relation entre les 2 tables ???
Merci encore!

krustypop · Answer

Merci beaucoup, mes requêtes marchent à la perfection, par contre lors de l'affichage du tableau il va falloir que je trouve un moyen de n'afficher que la partie type de consommable dans le tableau et ne pas répéter sur chaque ligne la même marque associé et le même modèle. Avez vous une idée ??

kohntark · Answer

Malalam = >
je ne suis pas d'accord : une imprimante accepte plusieurs types de
consommable...mais un type de consommable peut aussi fonctionner sur
plusieurs imprimantes.

Je suis bien d'accord avec toi, le but était de répondre de façon la plus claire possible à "je voudrais regrouper dans un tableau la marque et modele de mon
imprimante puis ds ce meme tableau tout les consommables associés à
cette imprimantes ainsi que leur quantités", en proposant un schéma de base et une requête qui permettait de le faire. Le "tiens nous au courant" était là pour proposer éventuellement un peu plus d'amélioration. Mon but n'est pas de pondre le script, et je ne pense pas que ce soit la demande de krustypop.

 "c'est toujours plus rapide avec un entier qu'avec un champ de type chaîne "  => là aussi 

Et puis comme toujours dans ce genre de cas, l'important reste de se poser les bonnes questions dès le départ, inutile d'implémenter des choses qui n'arriveront jamais. Certes, il reste possible qu'un utilisateur ait 10 imprimantes reliées directement à sa machine, mais, je ne l'apprends à personne, la tendance est aux imprimantes réseau ou partagé. Le moyen le plus simple reste donc d'identifier l'imprimante de par son nom (par extention ID dans la table)

krustypop => fais nous part de tes avancées et de ton code

Kohntark -

malalam · Answer

Kohntark => "inutile d'implémenter des choses qui n'arriveront jamais"
je suis d'accord, un code doit se contenter de faire ce qu'il devrait faire, pas plus...inutile de chercher midi à quatorze heures, mais une chose qui n'arrive qu'une seule fois, et qui n'a pas été prévue, est une catastrophe. Cela oblige svt à revoir le modèle de données, et le code avec. Quand on est en production, ce n'est jamais souhaitable. Et c'est du temps en plus. Et le temps...hein...c'est de l'argent :-)
Dans un projet, on a un cahier des charges. Le code et le modèle de données doivent coller à ce CDC. Mais ce CDC doit être capable de prévoir ce qui risque d'arriver, même une fois, sans quoi, dans un milieu professionnel, on fera perdre de l'argent, et du temps. 
Pour ce qui est de l'affichage, ça reste de l'affichage...ce n'est pas le code qui doit s'adapter à l'affichage, mais l'inverse. J'ai un modèle de données qui nécessite un tableau à X dimensions pour le représenter...on se démerde pour l'afficher le plus simplement et ergonomiquement parlant; on n'adapte surtout pas le modèle de données à l'affichage qui nous arrange. 
Et pour abonder dans ton sens...oui, en entreprise, on a svt des imprimantes partagées. Et il est rare qu'un utilisaeur n'accède, justement, qu'à une seule de ces imprimantes. Perso, au taf, j'en ai au moins 3 à dispo. C'est bien une relation n-n. 
Et pour l'ID, je ne comprends pa ta réticence ? Que ce soit un champ ou un autre, ça ne complexifie aucunement les requêtes.
Que je fasse (en suivant ton modèle, donc pas une relation n-n) :

SELECT usr.nom, imp.ref
FROM users usr
INNER JOIN imprimantes imp ON imp.imp_id = usr.imp_id

OU 

SELECT usr.nom, imp.ref

FROM users usr
INNER JOIN imprimantes imp ON imp.imp_ref = user.imp_ref

Je ne vois pas la différence? Sauf en terme d'utilisation des ressources. Même en tenant compte du fait que l'on a intelligement indexé le champ imprimantes.ref.

krustypop · Answer

tout ceci est bien constructif, je prends en compte toutes vos considérations et je vais essayer d'améliorer au mieux mon appli web. En tout les cas merci de m'aider dans mes débuts de "développeur" !! C'est cool les gars !!

kohntark · Answer

mais une chose qui n'arrive qu'une seule fois, et qui n'a pas été prévue, est une catastrophe.

= > nous sommes bien d'accord, je n'ai pas été suffisamment précis dans mon propos.
Il faut dire que trop souvent j'entends des personnes vouloir tout contrôler, de façon plus qu'exhaustive :
ex : un formulaire d'administration, protégé par htaccess, login ... et ils veulent faire un contrôle sur les données POST .... c'est absurde, il y a bien assez à faire pour parrer les attaques sur les zones exposées du site !

 Pour ce qui est de l'affichage, ça reste de l'affichage...ce n'est pas le code qui doit s'adapter à l'affichage, mais l'inverse 
 => pour t'avoir lu régulièrement je suis certain que là aussi nous sommes sur la même longueur d'onde mais qu'il s'agit d'un problème de compréhension ou d'expression. Le code doit s'adapter à l'affichage la plupart du temps, en tout état de cause lorsque son but est justement l'affichage (chui pas clair ? :) )
Ex : le post de karpediem : 
afficher le détail d'un lien dans un cadre [ Web 2.0 / Ajax ] 

Je cite : "je me demande si au moment de ma requête initiale, je n'aurais pas
intérêt à stocker toutes les informations, même celles du détails
quitte à ce qu'elles ne servent pas, pour éviter une deuxième requête à
ma base au moment où le visiteur demanderait le détail..."
Ben nan, clairement nan, c'est dans ce cas le "code" qui doit s'adapter à l'affichage, puisqu'il est prévu pour ça (afficher)

on a svt des imprimantes partagées. Et il est rare qu'un utilisaeur
n'accède, justement, qu'à une seule de ces imprimantes. Perso, au taf,
j'en ai au moins 3 à dispo

J'en ai au moins 50, raison de plus pour identifier l'imprimante en tant que telle en ce qui concerne la problématique de krustypop. D'ailleurs j'ai cru comprendre que c'est ce qu'il souhaitait faire, contrairement à ce que j'avais compris initialement (il m'a induit en erreur avec sa table utilisateur le bougre  )

krustypop => j'attends de tes nouvelles concernant le schéma que tu auras retenu.

Kohntark -

kohntark · Answer

Et pour l'ID, je ne comprends pa ta réticence ?



Quelle réticence ? Je me suis relu et je ne vois toujours pas.
Si tu parles de "=> là aussi " je me référais à ce que j'écrivais juste au dessus ("Je suis bien d'accord avec toi, [...]  ")

Kohntark -

malalam · Answer

Hello,

boah, côté sécurité...on en fait rarement trop quand même. Mais protéger des POST dont on ne va pas se servir en base, fichier etc...bref sur lesquels on fait juste un contrôle, c'est effectivement inutile.

Tu sors du contexte ce que j'ai dit :-) : je parlais là de code d'affichage. Une vue, quoi. En aucun cas le code structurel ne doit s'adapter à l'affichage, lui. Donc oui c'est bien une questin de vocabulaire : si j'ai besoin d'une relation n-n, je ne vais pas en faire une relation 1-1 juste parce qu'à l'affichage, je ne veux qu'une ligne... : le modèle de données serait totalement faux, et du coup, l'affichage absolument pas pertinent.

Et pour la réticence, je pense que c'est une incompréhension encore : évidemment que l'on va afficher le modèle de l'imprimante (par exemple), et pas son ID...mais la jointure, elle, doit se faire sur l'ID, indexé de préférence, et de toute manière à priori clef primaire.
Pour ton problème d'affichage, Krustypop, , ordonnes déjà ta requête sur le type de consommable, du coup, puis fais un bête test dans ta boucle de récupération : si type est vide OU !précedent type, alors on affiche type, et precedent type type. Sinon, que dalle.

Comment faire ma relation ??

15 réponses

Votre réponse

Discussions similaires