Forum d'entraide PHPFrance

Bonjour.
J'ai 2 tables MYSQL.
1- TABLE = client
avec article1, article2, article3.....article10. et (adresse, téléphone ect...)
chaque article a un numero genre KV381

2 TABLE = article
avec numero (de l'article genre KV381) , prix......(description)

Je voudrais afficher la table client avec les articles et prix correspondant.

J'essaye avec une jointure des 2 tables mais je coince après article1.
AND article2=numero (ou ODER BY article2=numero) ne marche pas

Voici mon code:
$q = 'SELECT client.article1 AS art1,client.article2 AS art2,article.prix AS px
FROM client
INNER JOIN article
ON article1=numero AND article2=numero';

$r = mysql_query($q);

while ($data=mysql_fetch_assoc($r))
{

Merci pour votre aide

salut,

ton problème montre bien le défaut de conception.
tes clients ne peuvent prendre que 10 articles (tu n'en vends / vendras pas plus ?)

la modélisation de base dans ce genre de cas est ainsi
- une table clients avec les informations du client (nom, prénom, téléphone, email, adresse bien que ces 3 derniers puisses être dans des tables séparées).
- une table articles : description, prix
- une table commandes date et idclient (tu peux ajouter un état une date de livraison, le type de paiement etc).
- une table lignesComandes idcommande id produit et quantité

donc un client peu avoir une ou plusieurs commandes avec un ou plusieurs articles.
pour avoir la liste des articles d'une commande
tu fais un select sur la table lignecommande avec l'id de la commande en predicat (where idcommande=xxx)
tu veux les commandes d'un client : select sur commande avec idclient en prédicat
tu veux tous les articles de toutes les commandes d'un client

select * from lignesCommandes
join articles using(idArticle) 
join commandes using(idcommande)
join clients using(idclient)
where clients.id=xxx

voilà comment faire la chose simplement, c'est extensible, pas doublon possible des données bref c'est maintenable simplement, du bonheur quoi


@+

Bonjour
Merci de la réponse si rapide.

Le client a qui j'envoie 10 articles (archets de violon, alto violoncelle....)en période d'essai n'en achètera qu'un (en général).
Les tables sont déjà créer depuis 10 ans.

J'envoie donc au client entre 1 et 10 articles (archets) . Pour l'instant j'arrive à faire un formulaire par client avec "article" et "prix" correspondant.

Mais maintenant j'aurai besoin de faire un récapitulatif par exemple de l'année 2016.
Donc à chaque client avec ces différents articles le prix correspondant . Voila pourquoi je teste les Jointures.

Les tables sont déjà créer depuis 10 ans.

c'est pas pour ce la qu'il ne faut pas changer
le gain en maintenabilité et simplicité est plus qu'intéressant.

le principe énoncé en haut est valable pour le prêt d'article ou autre il faut juste le bon modèle.

sans toucher aux tables il faut 10 jointures (parce que 10 colonnes article)

select c.nom, c.prenom (...), a1.description as desca1, a1.prix as prixa1, a2.description as desca2, a2.prix as prixa2 etc...
from client c
join article a1 on c.article1 = a1.id
join article a2 on c.article2 = a2.id
etc...

voilà

@+

encore merci !!

oui je pourrai changer la conception des tables...mais pour l'instant trop de code aussi à changer.

Je reprends le code
Et je n'ai rien qui s'affiche. Ais je fait une erreur

non c'est moi, je n'ai pas pensé à la règle de prêt qui est de 1 à 10 articles et 10 tout le temps

coup il faut des jointures "externe" pour retourner les lignes mêms si des jointures match pas

'select c.nom, c.prenom, a1.prix as prixa1, a2.prix as prixa2
from client c
left join article a1 on c.article1 = a1.id
left join article a2 on c.article2 = a2.id'

pour ce qui est de revoir les tables, il y a effectivement un coup, voir si le ROI (retour sur investisment) est valable ou pas (si tu fait 1 modification par an je ne pense pas, bien entendu si la modif dur 6 mois ce n'est pas la même chose que 2j dont un a te rappeler comment ça fonctionne ).
si tu souhaite externaliser la maintenance un jour oui surement.
C'est vraiment une question de contexte, mais en général je par du principe que je ne serais pas le seul à intervenir (peux être) et simplifier la chose au maximun pour tous c'est un poil mieux

@+

Bonjour
Merci beaucoup !!
En effet cela fonctionne.

Pour ce qui est de retouché les tables, je vais le faire mais comment s'y prendre ?

Pour l'instant j'ai
Table "client " que je rempli lorsque j'envoie des archets en essai.
Je mets les numeros des archets (genre KV447 ) ds article1, article2..... (le nbre que j'envoie) et le reste nom, prenom...ect

Id article1 article2...... nom prenom adresse.....dateenvoie dateretour


Table "article" que je rempli lorsque je fabrique un archet (numero KV447 par exple)
id numero prix instrument longueur poids ...............

Donc il me faudrait une une table commandes date et idclient : c'est la que mettrai les numéros des archets (article) avec idclient ?

la table article c'est bon.
La table client ne doit contenir que les infos clients, (nom, prenom, adresse, tel etc).
il faut donc une table de liaison entre les deux.
après il faut voir comment tu considère la chose, mais perso je ferais une table prêt et une table pour les ventes / commandes réelles.
après il est possible de se dire qu'il peux y avoir des retours sur une commande et du coup n'avoir qu'une commande avec la référence vers x articles et à la finalisation supprimer les articles qui ne sont pas gardés au final par le client.

Dans le cas de la table prêt
idpret : clef primaire
idclient: référence la clef primaire de la table client
idArticle : idem pour la table article. Attention ceci peux très bien être le numéro de l'article, du moment que c'est unique dans la table article. généralement on préfère un entier qui sert de clef technique (l'argument derrière c'est de meilleur perf sur l'indexation et la recherche sur un entier).
datePret : champ de type date (pratique pour suivre la chose
dateRetour : ce champ est null tant que l'article n'est pas rendu

si tu prête plusieurs article du même type alors une colonne quantité (mais a priori c'est des pièces unique donc inutile dans ce cas).
avec un select sur cette table tu sais ce que tu as prêté, à qui et quand (et surtout s'il l'a rendu ).

pour la commande / vente j'ai donné l'exemple avec deux tables (important) dans mon premier message.

si tu couple tous cela tu as une structure de base de données relativement efficace et souple.
Coté IHM tu peux, indépendamment, afficher la liste des prêts (complète ou en cours) ainsi que la liste des commandes.
Il est aussi relativement simple de créer une fonction pour transformer un prêt en commande / vente.

et du coup c'est aussi souple coté front

@+

La table vente est déjá à part, elle me sert de facturation ect.....

Donc je vais mettre au boulot, pour simplifier le tout.

Je te dis encore un grand merci !!

Au fait voici les archets que je fabrique ( le site web va être d'ici peut neuf)
www.archets-baroques.fr

Le nouveau pas encore 100 % fonctionnel
http://www.archets-baroques.fr/francais-2/index-fr.php

de rien, ça fait toujours plaisir d'aider

@+