Discussion :

[cretinus007]

Bonjour, je reviens vers vous pour une question, que je ne trouve pas sur les forums.

C'est un peu compliquer à expliquer, mais cest pour un e-commerce.
C'est pour mon panier le retour de mes articles. Mais les tables de ma BDD peuvents changer selon les articles.
J'ai par exemple des tables avec nom differents:
- animaux
- vetements
- bijoux etc...

J'ai la possibilité de rajouter un nouvel article ex: "tondeuse de jardin" donc une table sera créer avec le nom ex:"machines"
Donc ma question est comment faire une requête qui s'execute pour mes variables "$nom_de_table" de plusieurs tables

Exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
  for($i=0 ;$i < $nbArticles ; $i++){
        require('../includes/PDO.php');
	$req=("SELECT * FROM [=> animaux <=] * ici cette requête fonctionne avec text brut * 
        WHERE id='".$_SESSION['panier']['idprod'][$i]."'");
	$sql=$pdo->query($req);
	$retour=$sql->fetch(PDO::FETCH_ASSOC);
	echo'
	<td align="center">'.$retour['id'].'</td>';
}

Mais ici :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
for($i=0 ;$i < $nbArticles ; $i++){
        require('../includes/PDO.php');
	$req=("SELECT * FROM [=>".$_SESSION['panier']['tabbdd'][$i]." <=] * ici cette requête fonctionne pas du tout !!! * 
        WHERE id='".$_SESSION['panier']['idprod'][$i]."'");
	$sql=$pdo->query($req);
	$retour=$sql->fetch(PDO::FETCH_ASSOC);
	echo'
	<td align="center">'.$retour['id'].'</td>';
}

En gros il faudrai que la requête soie executée pour toutes les variables "$_SESSION['panier']['tabbdd'][$i]" en une seule requête.(si c'est possible)

Si une bonne âme a un raisonnement ou une solution je suis preneur ! Merci

[Séb.]

Il ne faut surtout pas utiliser ce modèle de bdd, c'est une aberration, et mène rapidement à des impasses comme celle à laquelle tu es confronté.

Plutôt que 1 table par catégorie de produits, il faut faire 1 table générale avec 1 colonne catégorie.

Actuellement :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
vêtements (id, libellé, etc.)
---------------
1, Pull, etc.
2, Blouson, etc.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
bijoux (id, libellé, etc.)
---------------
1, Collier, etc.
2, Bracelet, etc.

Alors qu'il faudrait :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
produits (id, libellé, catégorie, etc.)
---------------
1, Pull, Vêtement, etc.
2, Blouson, Vêtement, etc.
3, Collier, Bijou, etc.
4, Bracelet, Bijou, etc.

Ton panier n'aura qu'à stocker produits.id et une quantité, plus de noms de table à gérer, et tes requêtes interrogeront une table unique produits.



PS : et que fait un require 'PDO.php' dans une boucle ? C'est plutôt le genre de truc qu'on met en début de script

[jreaux62]

Bonjour,

il faut aller plus loin.

1- il faut une table t_categories :

• id_categorie (INT, auto-incrément)
• nom_categorie

2- Et la table t_produits :

• id_produit (INT, auto-incrément)
• id_categorie (INT)
• libelle_produit
• ...

3- la requête, avec JOINTURE SQL :

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
SELECT ... 
FROM t_produits P
INNER JOIN t_categories T
   ON P.id_categorie = T.id_categorie
...

[cretinus007]

Bonjour et merci pour votre réponse a vous Seb et jreaux62:
Désoler pour ma réponse tardive.
J'avais voulu simplifier la gestions des tables,dossiers et chemin d'acces avec mon schema de tables...Mais bon on peut ce trompé

Donc vous me proposer deux solutions différentes, mais laquelle est la meilleure ?

Quelles est la meilleure solution sur les possibilités des requêtes (y compris une barre de recherche)?
Quelles est la meilleure solution sur une table contenant beaucoup d'articles ?

Jreaux62 pour aller plus loin, si j'ai bien compris pour la tab_categories on join la tab_produits avec le même id_categorie ?
Ce qui reviens à une tab_produits et 1 colonne categorie (comme Seb la mentionné) ?
Votre solution offre-t-elle plus de possiblités au niveau des requêtes et gestion ou simplifie a un certain niveau ?
Si c'est le cas je suis preneur d'en savoir un peu plus !

[Séb.]

Donc vous me proposer deux solutions différentes, mais laquelle est la meilleure ?

Idéalement, pour coller aux bonnes pratiques, il faut 2 tables : produits et catégories, et faire une jointure pour récupérer le libellé, comme illustré par jreaux62
Au prix de la gestion de la table supplémentaire cela permet une maintenance simplifiée, une bonne finesse et une bonne évolutivité (ex. des catégories de catégories, des données supplémentaires, un affichage spécifique selon d'autres colonnes)

Bon après si ta table catégories finit avec 4 enregistrements qui se battent en duel il est plus simple d'utiliser une colonne produits.catégorie ENUM('Vêtements', 'Bijoux', etc.), c'est le cas type d'une colonne utilisateurs.statut ENUM('Actif', 'Inactif') => J'ai pas envie de créer une table pour 2 lignes
Ceci dit, rien que récupérer la liste des catégories est déjà plus difficile et te force à faire une requête peu naturelle (SELECT DISTINCT catégorie FROM produits) (ce qui n'est pas grave si tu as peu de produits ou un index)

Voilà, donc je dirais, à toi de voir

(Perso je prendrais 2 tables, plus haut l'exemple simpliste avait pour objectif unique d'illustrer le principe de la table unique de produits)

[jreaux62]

Je suis d'accord avec moi-même.

Ex. d'inconvénient d'une seule table produit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
produits (id, libellé, catégorie, etc.) --------------- 
1, Pull, Vêtement, etc. 
2, Blouson, VETEMENT, etc.
3, Blazer, Vetement, etc.

Vêtement - VETEMENT - Vetement : sont considérés comme différents !

Alors qu'avec 2 tables, plus de problème.
Même avec seulement 2, 3 ou 4 catégories.

N.B. et que dire, si le site est multilingue ?

[Séb.]

Vêtement - VETEMENT - Vetement : sont considérés comme différents !

En temps normal non :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT 'Vêtement' = 'VeTeMeNt'; -- 1

Par contre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT BINARY 'Vêtement' = 'VeTeMeNt'; -- 0

[escartefigue]

Tout dépend de la collation !

Si la collation est "case sensitive" (CS) les majuscules/minuscules sont distinctes (A <> a), sinon (CI) elles sont confondues
Si la collation est "accent sensitive" (AS) les accent sont distincts (e <> é), sinon ils sont confondus

[jreaux62]

OK,

1- je vous le refais :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
produits (id, libellé, catégorie, etc.)
--------------- 
1, 'Pull', 'Vêtement', etc. 
2, 'Blouson', 'Vêtement ', etc. 
3, 'Blouson', 'Habit', etc.

'Vêtement' - 'Vêtement ' - 'Habit' : sont différents (noter l'espace à 'Vêtement ')
C'est plus clair, ou toujours pas ?


2- Et comme un exemple (récent) vaut mieux qu'un long discours :

• https://www.developpez.net/forums/d2.../#post11789372

je n'avais pas remarqué que j'avais écrit Arts soit en majuscule soit en minuscule .
Idem avec SPORTS & SANTE ( problème d'espaces à bannir !)

3- Quant à la "collation"...

• il me semble que sur les serveurs distants (FAI), c'est généralement "case sensitive"

4- CONCLUSION :

• Avec 2 tables, on n'a aucun de ces problèmes.
  CQFD.

[Séb.]

il me semble que sur les serveurs distants (FAI), c'est généralement "case sensitive"

C'est comme on le définit à la création de la base/table/colonne.

[jreaux62]

On est dans le forum PHP.
Pas SQL.

[escartefigue]

On est dans le forum PHP mais dans la partie PHP & base de données

Ce faisant, il faut connaître la collation pour savoir comment se comportent les chaînes de caractères lors des tris, des regroupements et des comparaisons.
En fonction des SGBD, cette collation peut être définie au niveau du serveur, de la table et de la colonne, mais aussi être forcée dans l'ordre SQL.

On peut tout à fait avoir des collations différentes dans deux tables d'une même base de données ou dans deux colonnes d'une même table.
Ce n'est pas le plus fréquent, mais ça existe.
C'est pourquoi il faut savoir à quelle collation on a affaire pour traiter correctement les chaînes de caractères dans les ordres SQL.


Edit : le défaut de maîtrise des collations peut être une source de déconvenues lors d'un changement d'hebergeur, telle requête qui produisait tel résultat en produit soudain un autre... Classique !

[jreaux62]

[...]

Ça devient pénible ces discussions à rallonge, alors que la question initiale a reçu sa réponse !!!


N.B. J'ai dit ce que j'avais à dire dans mon message #3.
Tout le reste est du blabla inutile.

[Séb.]

[...]

Ça devient pénible ces discussions à rallonge, alors que la question initiale a reçu sa réponse !!!


N.B. J'ai dit ce que j'avais à dire dans mon message #3.
Tout le reste est du blabla inutile.

Tout à fait, et la réponse au besoin initial à été apportée au message #2.

Quand a donc commencé le "blabla inutile" au sujet ?

[escartefigue]

@Jreaux62 : plutôt que de vous agacer inutilement, relisez la question initiale et notamment son titre qui est "requêtes SQL combinées en une seule"

D'ailleurs, les réponses qui précèdent, notamment les vôtres, font des observations légitimes sur la modélisation des données hasardeuses.
Si on suit votre raisonnement, ces réponses seraient hors propos sous pretexte qu'on est dans le forum PHP ? Bien sûr que non.
De plus, je maintiens que gérer des chaînes de caractères sans s'assurer de la collation est une erreur.


Sachez par ailleurs que votre intervention avait déjà été "moinsée" avant même que je réponde, comme quoi

[jreaux62]

Non,

la réponse, TU l'as donnée dans TON message #5, qui faisait la synthèse de TON message #2 et de MON message #3 (les 2 solutions possibles).

Dans mon message #6,
j'ai cru bon* de donner un exemple où la solution 1 (#2) pouvait poser problème.
Ne n'ai retrouvé le lien vers la discussion concernée (exemple concret) que plus tard.

* Je m'en abstiendrai, la prochaine fois.


A partir du moment où la réponse a été donnée, et qu'on était d'accord sur le principe, il était inutile de "blablater"...
escartefigue devrait le savoir, puisqu'il est modérateur.

@escartefigue
Merci de ne pas me prendre de (trop) haut.

Quant au moinssage anonyme, je me suis déjà exprimé dessus.
Si "supprimer des réponses" est discourtois, "moinsser" anonymement (et sans explication) est lâche.


N.B. J'EFFACERAI CE MESSAGE, après lecture.