Discussion :

[RunCodePhp]

Les choses se compliquent sérieusement.
Un modèle pour obtenir un menu avec suffisamment de souplesse, passe encore, mais là, ça devient quasi mission impossible de te donner une solution qui répondrait (à coup sûr) à ton besoin.

Il y aura beaucoup trop d'inconnues. Faut avoir une idée quasi précise sur l'ensemble du projet, car les choses sont toutes liées entre elles.

Exemple.
Tu donne comme info dans un champ : dimensions.
Vu que précise que c'est un site multilingues, les unités de mesures ne sont pas les mêmes ne serait ce qu'entre le Français et l'Anglais.
Idem pour les tailles, pointures etc ...
Même chose pour le poids.
Et encore, je ne parle même pas des devises, de la fiscalité.
Tout ceci a inévitablement un impacte sur la Bdd. Il faut pouvoir les représenter.

Et pour se qui est des infos comme : couleur, matière, pointure
Celles ci ont encore la particularité de ne pas être communes à tous les produits, du moins j'en doute fort. Ce qui fait quelles ne devront pas être placées dans la table "articles", mais au moins dans une autre table, et même plusieurs.

Mais ... c''est le volume que cela risque de représenter.
Imagine un instant le cas typique d'un tee shirt, avec comme particularité :
genre : homme, femme, enfant
taille : S, M, L, XL, XXL
couleur : rouge, orange, vert, bleu, blanc
Rien que pour 1 seul tee shirt ça débouche sur 75 combinaisons potentiels.
Tu rajoute juste 1 couleur : 90
Tu généralise ceci sur pleins de produits, la Bdd en prend un sacré coup.
Faut au moins en avoir conscience.


Il y a des moyens pour rationaliser ça, mais ceci demande d'avoir plus d'infos sur le projet.
L'exemple typique c'est si tu compte par exemple gérer le stock sur chacun des éléments, comme de la table, à la paire de chaussure truc de couleur bleu de taille XY.
Et même si tu ne gère pas totalement le stock, mais par exemple juste pouvoir avertir que le tee shirt (Femme,L,rouge) ne serait plus dispo, mais le tee shirt (Femme, L, orange) lui est dispo.

Un 2ème exemple c'est au niveau des statistiques.
Si tu projette d'avoir des infos comme savoir quelle serait les couleurs des tee shirt les plus vendus, ou des tailles des chaussures, des modèles ou références, etc, etc ... tout ceci débouche très certainement sur un modèle de Bdd différent.
Les besoins sont pas les mêmes, et la quantité de données risques du coup d'être très différentes.

Vu la grande variété des articles que tu décris, ça me semble impossible de savoir comme ça quel serait le modèle qui pourrait les représenter.
Ca demande réflexion.
Chose impossible comme ça sur un forum.


Ca va faire 3 fois que je le dis, tant pis, mais la solution la plus raisonnable se trouve ailleurs à mon sens, parmi les Soft (entre autre Open source).
Il en existe beaucoup, du plus simple au plus évolués, et pour les Soft Open Source, ils offrent tous une démo, ou mieux, les télécharger.
Il devrait avoir au moins un qui s'approche à ton besoin.

Pour ma part, je ne vois pas pourquoi tu t'obstines à créer de A à Z un site e-commerce alors qu'un tel projet est complexe, car il ne s'arrête pas à créer un menu et une table de produits, mais il y a toute la gestion des clients, du panier, des commandes, les livraisons, le paiement en ligne, et surtout la sécurité de tout ça. Et bien d'autres encore.
Tu risque d'y passer des mois, c'est même certain.

[redah75]

Bonjour RunCodePhp, de retour apres un mois de silence
pour le menu, j'ai adopté la solution que tu m'as proposée, elle est la plus simple et complete

je me pose actuellement des questions quant a la conception de la base de données articles. j'hesite enormement entre l'utilisation d'un open source comme PrestaShop ou si je fais le tout a la main, meme si cela prendra des mois, ca sera au moins un outil maison qui repondra a mes attentes...

c'est clair que je vais devoir proposer plusieurs devises et langues, je suis un peu largué et ne sais trop a quoi avoir recours!!
je developpe pas mal en PHP, est il quand meme interessant de tout faire a la main sachant que j'utiliserai bp jquery et ses plugins qui facilitent et simplifient enormement le travail... ??
aurais tu un exemple de tables mysql pour un site ecommerce?

Merci beaucoup

[redah75]

Bonjour les gars, j'espere que vous allez bien depuis notre derniere conversation
je me permets de reanimer ce topic dont je suis l'auteur car la je reprend le travail sur ce projet, j'avais qlq ennuis de santé

j'ai bien relu vos reponses et reflechis et je trouve que la solution de RunCodePhp est la mieux adaptee. je l'ai un peu ameliorée en rajoutant une colonne pour satisfaire mon besoin que voici:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
Table menu
id_cat | id_parent | id_libelle
--------------------------
1      | 0        | 1  // niveau 1 (Maison)
2      | 0        | 2  // niveau 1 (Mode)
3      | 1        | 3  // niveau 2 (Maison -> Salon)
4      | 1        | 4  // niveau 2 (Maison -> Salle de bain)
5      | 3        | 5  // niveau 3 (Maison -> Salon -> Luminaire)
6      | 3        | 6  // niveau 3 (Maison -> Salon -> Tables)
7      | 3        | 7  // niveau 3 (Maison -> Salon -> Chaises)
8      | 4        | 5  // niveau 3 (Maison -> Salle de bain -> Luminaire)
 
Table menu_traductions //j'utilise 'fr' au lieu d'un id num pour simplifier
id_lib | lang | libelle
--------------------------
1      | fr   | Maison
2      | fr   | Mode
3      | fr   | Salon
4      | fr   | Salle de bain
5      | fr   | Luminaire
6      | fr   | Tables
7      | fr   | Chaises
...

l'avantage de cette structure c'est qu'on peut avoir un element de niveau 2 ou 3 dans plusieurs rubriques. dans cet exemple, "Luminaire" est dans "Salle de bain" et "Salon"

qu'en pensez vous?? auriez vous de meilleures idees??
MErci infiniment

[_Mac_]

De mon côté rien à redire, c'est ce que je trouve de mieux.

[redah75]

MErci _Mac_ pour ta reponse, tu me rassures et egalement un grand merci a RunCodePhp pour la solution qu'il m'a donnée.

je profite de ce post pour te poser 2 autres questions que j'ai posté ici: http://www.developpez.net/forums/d95...s/#post5350221 mais je n'ai pas eu de reponse convaincante!!

1- est il conseillé d'utiliser des identifiants numeriques pour les langues et pays ou plutot leur code ISO (fr, en es)??

2- j'ai une base de donnees en utf8 et mes pages web sont toutes declarees en utf8 : <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
Lorsque j'insere des caracteres accentués, faut il qu'il y est le caractere 'é' ou 'é' ou '&eacute;' pour la lettre 'é' ??
pour info, j'utilise mysql 5

Merci infiniment

[RunCodePhp]

Tu as fais une erreur pour les langues (ton post au-dessus) :
Table menu
id_cat | id_parent | id_libelle
Table menu_traductions //j'utilise 'fr' au lieu d'un id num pour simplifier
id_lib | lang | libelle

Il n'y a pas besoin d'avoir d'id_libelle.
Une catégorie est unique (id_cat), et pour les langues, c'est leur couple id_cat/id_lang qui va garantir leur unicité, donc de permettre de rechercher le libellé selon 1 catégorie et 1 langue (jointure de table).

Le modèle est tout simplement :

Code :

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

1
2
3
4
5
6
7
8
 
id_cat | id_parent
1     | 0
 
Table menu_traductions
id_cat | lang | libelle
1     | fr     | Maison
1     | en   | House

Coté Bdd, il faut créer une clé primaire double : PRIMARY KEY (id_lib, lang)
Il faudrait effectivement utiliser des IDs (nombres) pour les langues, c'est plus efficaces.

1- est il conseillé d'utiliser des identifiants numeriques pour les langues et pays ou plutot leur code ISO (fr, en es)??

Il n'y pas d'hésitation a avoir à mon sens, et c'est un ID (nombre) qu'il faudrait comme clé primaire, car une Bdd ça fonctionne mieux avec des nombres.
De plus, coté applicatif, un nombre est plus facile à vérifier, à imposer que des chaines de caractères.
Mais encore, et si la norme change pour quelque raisons que ce soit, tu auras nettement moins de problème (voir aucun).
Cette table "langue" te permettras d'avoir des champs (genre ISO), que tu pourras exploiter là où ce sera nécessaire.
Pour les problèmes de cherset ou d'encodage, recherche coté tuto dans ce forum, la démarche est expliquée, sans compter qu'il y a des topics aussi.

l'avantage de cette structure c'est qu'on peut avoir un element de niveau 2 ou 3 dans plusieurs rubriques. dans cet exemple, "Luminaire" est dans "Salle de bain" et "Salon"

On peu le faire, et ça se fait, et en général c'est pour augmenter la visibilité.
Mais faut avoir conscience que ceci peu par exemple provoquer une boucle infinie si on crée une fonction récursive sans garde fou.
De même que rendre les recherche moins pertinentes (moteur interne) car obtenir plus de résultat s'il n'y avait pas de croisement.
Mais encore, c'est de rendre la navigation chaotique ou déroutante pour les internautes.
Bref, dans les croisements, faut savoir ce qu'on fait.

Mais il me semble avoir expliqué aussi que les croisements pourront aussi se faire au niveau des produits.
D'ailleurs, faut savoir que ce sont des produits que tu vas vendre, et non des catégories, donc ce sont des produits que chercheront les clients.

[redah75]

On peu le faire, et ça se fait, et en général c'est pour augmenter la visibilité.

comment le ferai tu?? je ne vois vrmt pas comment sans la colonne que j'ai rajoutee.
pourrais tu me donner le meme exemple que j'ai mentionné (Luminaire dans Salle de bain et Salon) avec ton schema ??

Pour les problèmes de cherset ou d'encodage, recherche coté tuto dans ce forum, la démarche est expliquée, sans compter qu'il y a des topics aussi.

je n'ai pas trouvé de lien ou une reponse pertinente a ce sujet. aurais tu des liens a me donner??

Merci

[RunCodePhp]

comment le ferai tu?? je ne vois vrmt pas comment sans la colonne que j'ai rajoutee.
pourrais tu me donner le meme exemple que j'ai mentionné (Luminaire dans Salle de bain et Salon) avec ton schema ??

En créant une autre table pour croiser des catégories par exemple.
Des couple de cat_id (une catégorie lié a une autre catégorie).
Mais là on peu faire tout et n'importe quoi, donc faut faire gaffe.

Mais il y a un autre aspect que tu n'as peut être pas visualisé, car jusqu'à maintenant tu t'es focalisé sur les catégories, tu oubli les produits.

Donc comme il faudra une table qui associera les catégories et produits, donc : cat_id | prod_id
Donc ici, admettons que tu mettes 2 fois le même produit (même ID) dans 2 catégorie différentes : id_cat 3, id_cat 7
Ca veut dire que lorsque tu affiche la catégorie 3 (salle de bain), il pourra être possible de récupérer la catégorie 4 (chaises) aussi (grâce à leur produit communs).
Coté SQL on dit que ce sera une jointure extérieur.
Pas besoin de crée de champ ni de tables supplémentaire pour ça.
Mais là encore il faudra faire gaffe, faut savoir ce qu'on fait dans ces croisements.
C'est à mon sens plus "casse gueule" que mon 1er exemple, mais plus optimisé.

Mais on peu créer des tables pour croiser des produits entre eux aussi (comme pour les catégories que j'ai dis précédemment), ça augmente encore les possibilités.


Mais il faut que tu fasse des essai réels, avec des catégories et des produits pour visualiser tout ça.
Mais avant de faire des truc plutôt déroutant, qui demande de la pratique, fait quelque chose de carré, propre.
Les astuces viendront par la suite.


Mais rajouter un champ libellé dans la table catégorie, ça me semble pas correcte comme concept.

je n'ai pas trouvé de lien ou une reponse pertinente a ce sujet.

Je ne crois pas 1 seconde.
La haut, il y a un lien FAQ PHP. Puis une zone de recherche.
J'ai saisi "charset", et hop, une liste apparait, et qu'est-ce que je vois :
Comment utiliser de l'UTF-8 avec PHP / MySQL ?
10 secondes (à peine)
Mais si tu saisi "php mysql utf-8" dans GG, il y en a des tonnes.
Et le 1er en tête n'est pas mal non plus : UTF-8 PHP MYSQL (histoire d'encodage)
Si tu cherche pas, tu ne trouveras pas

[redah75]

Je ne crois pas 1 seconde.
La haut, il y a un lien FAQ PHP. Puis une zone de recherche.
J'ai saisi "charset", et hop, une liste apparait, et qu'est-ce que je vois :
Comment utiliser de l'UTF-8 avec PHP / MySQL ?
10 secondes (à peine)

merciiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii t'es mon sauveur!!
et je te jure que j'ai cherche pdt des heures et des heures, j'ai ete sur au moin 30 forums et je n'ai pas trouve mon bonheur.
je tapais sur google "inserer caracteres accentués mysql utf8" et je n'ai vu nul part parler de mysql_query("SET NAMES 'utf8'"); qui etait la solution. j'ai mnt les caracteres qui sinserent dans la bdd exactement comment a la saisie.
Merci infiniment

En créant une autre table pour croiser des catégories par exemple.
Des couple de cat_id (une catégorie lié a une autre catégorie).
Mais là on peu faire tout et n'importe quoi, donc faut faire gaffe.

Oh lalaaaaa, je sens que ce menu ne sera jamais fini (
c'est claire que j'aurais une table pour associer les produits aux categories mais puisque tu dis qu'il faudrait creer une autre table pour croiser les categories, pourquoi ne pas faire plus simple et leger avec cette structure?:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
Table menu_elements
id_elmt | niveau | valid
--------------------------
1       | 1
2       | 1
3       | 2
4       | 2
5       | 2
6       | 3
7       | 3
8       | 2
 
Table menu_elements_traductions
id_elmt | lang | libelle
--------------------------
1       | fr   | Maison
2       | fr   | Mode
3       | fr   | Salon
4       | fr   | Salle de bain
5       | fr   | Chaussures
6       | fr   | Tables
7       | fr   | Luminaire
8       | fr   | Cuisine
 
Table menu_structure
id_elmt | id_sous_elmt
--------------------------
1       | 3
1       | 4
1       | 8
2       | 5
3       | 7
4       | 7
3       | 6
...

j'ai fait des simulations et cette structure me parait couvrir tous les cas et offre une meilleure souplesse:
- pour afficher les elements de niveau 1 ou 2: la requete est simple
- pour afficher les produits de type luminaire, la requete est simple
...

dis moi stp que c'est bon pour en finir
_MAC_ avait approuvé une solution similaire que j'ai proposé le mois dernier...

Merci encofe une fois les gars pour votre contribution. j'aimerais tellement vous offrir une biere pour vos efforts...
Merci

[RunCodePhp]

dis moi stp que c'est bon pour en finir

Je t'ai pourtant donné 2 façons de croiser des catégories, et à mon sens 2 bonnes façons de faire, celles qui respectent les bon concepts d'une Bdd.
Ce que tu fais, ce n'est pas de l'optimisation, et indiquer le niveau, ça j'avais déjà expliqué il me semble, qui te démontrais que c'est inutile, c'est redondant.
Tu fais une vrai fixation la dessus, sérieux, ça ne sert à rien, mais vraiment.

De plus, je ne vois pas ce que vient faire le nom "menu_elements" la dedans ?
Ou est le rapport avec les catégories (id_cat) ?
Pourquoi veux tu faire des menus en plus des catégories (si c'est le cas) ?
Si "menu_structure" c'est "catégorie", pourquoi avoir changé de nom alors, on comprend plus rien.


Je ne vois rien ici qui ne serait pas ou moins optimisé.
Tu parts du principe qu'une table supplémentaire serait automatiquement moins performant. ce sont des (gros) pré-jugés.
D'ailleurs, il est courant de rajouter des tables pour optimiser une appli, ça se fait particulièrement au niveau des stats.



Pour les 2 solutions :
- Si tu utilise la technique de la table spécifique, s'il n'y a pas de croisement, il y aura strictement aucun enregistrement, aucune ligne. Pas de superflu.
Si tu crée des croisements, il y aura donc uniquement les lignes concernées (pas une de plus, pas une de moins).
- Si tu utilise la technique des croisements au niveau des catégories/produits, s'il n'y a pas de croisement, il n'y aura pas de ligne. Pas de superflu.
Avec des croisements, il y aura uniquement les lignes concernées.
Dans les 2 cas, il faudra mettre une clé primaire double, ce qui empêchera la duplication.

Je ne sais pas si tu vois la différence, mais elle est énorme, de taille, car les croisements reposent sur des relations (ou liaisons, ou jointure), et non pas sur une info (quasi) isolée.
Les relations sont la base même des Bdd, et c'est cela qui change tout (quand c'est bien conçu).


C'est comme ça que ça se fait, et j'y peu rien, et je ne vois pas comment expliquer ça autrement.
Maintenant, libre à toi de faire comme tu veux, évidemment.

[redah75]

RunCodePhp, tu vas finir par me detester )

Je t'ai pourtant donné 2 façons de croiser des catégories, et à mon sens 2 bonnes façons de faire, celles qui respectent les bon concepts d'une Bdd.
Ce que tu fais, ce n'est pas de l'optimisation, et indiquer le niveau, ça j'avais déjà expliqué il me semble, qui te démontrais que c'est inutile, c'est redondant.
Tu fais une vrai fixation la dessus, sérieux, ça ne sert à rien, mais vraiment.

tu m'a parlé d'une table pour croiser les categories; cette table me parait un peu bizarre car il y a comme une sorte de redondance. la table principale definit elle meme l'arborescence, je ne vois pas pourquoi creer une autre table qui fera presque la meme chose et qui completera le comble de la table principale...
Pour etre clair et precis. le 1er model que tu m'as preconisé est le suivant:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
Table menu
id_cat | id_parent
--------------------------
1      | 0
2      | 0
3      | 1
4      | 1
5      | 3
6      | 3
7      | 3
8      | 4
 
Table menu_traductions
id_cat | lang | libelle
--------------------------
1      | fr   | Maison
2      | fr   | Mode
3      | fr   | Salon
4      | fr   | Salle de bain
5      | fr   | Luminaire
6      | fr   | Tables
7      | fr   | Chaises
8      | fr   | Luminaire
...

ce qui me derange la c'est "Luminaire" qui est repeté 2 fois et avec 2 identifiants differents. ceci m'empecherai d'afficher facilement tous les produits du type "Luminaire"... on est d'accord???

pour y remedier, je vois une solution simple qui est de ne pas avoir le champ id_cat de la table menu en primary key et en auto increment pour pouvoir avoir qlq chose du genre:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
Table menu
id_cat | id_parent
--------------------------
1      | 0
2      | 0
3      | 1
4      | 1
5      | 3
6      | 3
7      | 3
5      | 4
 
Table menu_traductions
id_cat | lang | libelle
--------------------------
1      | fr   | Maison
2      | fr   | Mode
3      | fr   | Salon
4      | fr   | Salle de bain
5      | fr   | Luminaire
6      | fr   | Tables
7      | fr   | Chaises
...

Qu'en penses tu?

Sinon, la solution que tu m'as donné qui consiste a rajouter une autre table pour croiser les categories. je t'avoue que j'ai un peu de mal a l'imaginer. pourrais tu STP me donner une petite simulation comme ce que je viens de faire au dessus afin que je comprenne mieux...

J'aimerais aussi que tu me dises ce qui ne va pas dans le model que j'ai mentionné dans le post #29

et vraiment desole si j'ai un peu de mal a te comprendre

Merci

[RunCodePhp]

ce qui me derange la c'est "Luminaire" qui est repeté 2 fois et avec 2 identifiants differents. ceci m'empecherai d'afficher facilement tous les produits du type "Luminaire"... on est d'accord???

Arff, j'suis à 10 000 Kms, le soleil n'est pas l'même, on ne vois pas la même chose alors.

Prenons les choses dans l'ordre.
Ca commence par les catégories dont le parent vaut 0 (truc imposé).

Niveau 1
Donc cat_id 1 et cat_id 2.
Jusque là, tout va bien.

Après, (admettons) on lance une requête qui retourne les catégories de 1 et 2 :
Niveau 2
Pour cat 1 : cat_id 4 | cat_id 3
Pour cat 2 : rien

Maintenant, celles de 3 et 4 (de cat parent 1)
Pour cat 3 : cat_id 5 | cat_id 6 | cat_id 7
Pour cat 4 : cat_id 8

Ou est le problème ?

C'est toi qui est en faite en train de donner le même nom pour 2 catégories qui sont en faites différentes.
Faut pas donner le même nom, tout simplement, appelle la Cuisine, et il n'y a plus de problème.
Et il n'y a pas de croisement ici, juste une catégorie de plus.

pour y remedier, je vois une solution simple qui est de ne pas avoir le champ id_cat de la table menu en primary key et en auto increment pour pouvoir avoir qlq chose du genre:

Non mais là, rien ne va plus.
Faut même pas y penser, autant rien faire, ou faire autre chose que de la Bdd.

Pourquoi vouloir à tout prix simplifier quelque chose qui ne peut pas se simplifier ? (encore que là, c'est un bien grand mot)
La base de donnée c'est un truc qui ne se fait pas au pif, loin de là


Pour croiser des catégories entre elles :
Table "categories_croisees"

Code :

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

1
2
3
 
id_cat | id_cat_croisee
 4       | 5

Donc ici, pas besoin de catégorie supplémentaire (pas de 8) dans la table "categorie", on indique à la catégorie 4 quelle est croisé avec une autre catégorie 5
Une simple requête suffit pour recherche toutes les catégories liées.
Qui a t-il de compliqué


Sérieux, les 2 concepts que je t'ai donné ne sont en rien de la redondance, c'est justement des tables qu'on crée pour représenter un besoin qu'on a, ça débouche sur des relations entre des identifiants.
Donc c'est parfaitement normal qu'on retrouve ces Ids.
Mais d'un coté, table catégorie, le id_cat est la clé primaire, et si on crée une table pour croiser des catégories, dans celle ci le id_cat sera une clé étrangère (Foreign Key) et l'autre aussi.
Mais on rassemblera ces 2 clés étrangère en 1 seule clé primaire double : id_cat | id_cat_croisee.
Ca peu paraitre particulier, mais je t'assure qu'il y a vraiment rien d'anormal, bien au contraire.


Dans ton exemple (post plus loin), les croisement étaient effectués dans un champ supplémentaire, alors que de toute évidence, ça doit être des lignes.
1 ligne vaut 1 croisement.
Si un jour on ne veux plus du croisement, une simple suppression suffira.
Et toute l'application fonctionnera parfaitement, sans l'ombre d'un problème.

De ton cas, si on supprime ce croisement, l'ID 8 n'y sera plus.
Et bien ça, ça peut être un sacré gros problème, énorme même pour peu que tu la lie avec autre chose, voir que cet ID soit dans des documents imprimés.
La, tu seras coincé.
Est ce que tu vois mieux ici pourquoi ce n'est pas correcte ?


Si un jour tu propose des paire de basket classés dans une catégorie "chaussure" et que tu veuille proposer à coté des ballons de foot classés dans une catégorie "sport", comment feras tu alors ?
(sinon de créer des couples d'IDs de produits).


Je ne peux pas faire plus, et je suis à bout d'arguments.

[redah75]

Donc ici, pas besoin de catégorie supplémentaire (pas de 8) dans la table "categorie", on indique à la catégorie 4 quelle est croisé avec une autre catégorie 5
Une simple requête suffit pour recherche toutes les catégories liées.
Qui a t-il de compliqué

hehe y a rien de compliqué, c'est juste que ca me parait un peu bizarre de faire la moitie du boulot dans la table principale "menu" (cat 4 -> cat_id 8) puis l'autre moitié dans "categories_croisees" (cat 4 -> cat_id 5)
et ce que je me dis c'est que, tant qu'a faire, pourquoi ne pas mettre toute la hierarchie dans une seule et unique table comme montre dans un post precedent que revoici:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
Table menu
id_cat | niveau | valid
--------------------------
1      | 1
2      | 1
3      | 2
4      | 2
5      | 2
6      | 3
7      | 3
8      | 2
 
Table menu_traductions
id_cat | lang | libelle
--------------------------
1      | fr   | Maison
2      | fr   | Mode
3      | fr   | Salon
4      | fr   | Salle de bain
5      | fr   | Chaussures
6      | fr   | Tables
7      | fr   | Luminaire
8      | fr   | Cuisine
 
Table menu_structure
id_cat | id_sous_cat
--------------------------
1      | 3
1      | 4
1      | 8
2      | 5
3      | 7
4      | 7
3      | 6
...

ne fais pas attention a l'appelation des colonnes
tu ne m'as au fait toujours pas dit ce qui ne vas pas avec ce schema!!

j'espere que la les choses sont claires et que tu as bien compris ou je veux en venir!!

[RunCodePhp]

c'est juste que ca me parait un peu bizarre de faire la moitie du boulot dans la table principale "menu"

Non, la table "categorie_croisees" n'est absolument pas un menu, c'est juste des croisements de catégories, et uniquement.
Le menu, c'est la table "categories" qui permettra de le construire.
Ce sont 2 aspect radicalement différent.

Et tu oubli aussi que je t'avais proposé 2 solutions, dont l'autre ne réclamait pas de table supplémentaire, mais qu'un croisement pouvait se faire en rajoutant une simple ligne dans une table qui existera obligatoirement.
Table "categories_produits"

Code :

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

1
2
3
4
 
id_cat | id_prod
4      | 1
5      | 1

La théorie (ou la logique) veut qu'un produit soit lié à 1 seule catégorie.
Mais pour apporter un supplément de visibilité, on souhaite souvent lier des produits dans d'autres catégories.
Et bien ici, on pourra aussi obtenir les autres catégories qui auront des produits en communs pour 1 catégorie en particulier.
Ici, c'est de loin le plus juste, car c'est la duplication qui dicte la présence ou non du croisement, donc ne sera proposé QUE les catégories croisées ayant des produits.
La aussi on peu difficilement faire plus simple (une simple ligne).

Dans les 2 solutions, les modèles sont 100% basés sur des relations, et uniquement.

j'espere que la les choses sont claires et que tu as bien compris ou je veux en venir!!

Non,je ne vois pas vraiment où tu veux en venir.
Ton modèle n'est pas totalement basé sur du relationnel, mais d'un aspect humain je dirais, ce champ "niveau" relève à mon sens de l'interface, c'est une indication purement fictive, si on peu dire.


Et puis il me semble que j'ai déjà suffisamment expliqué, je l'ai déjà dis, je suis à bout d'argument.

Tu veux faire autrement, et bien fait autrement.
Qu'est ce que tu veux qu'on dise de plus ?

[redah75]

Non, la table "categorie_croisees" n'est absolument pas un menu, c'est juste des croisements de catégories, et uniquement.
Le menu, c'est la table "categories" qui permettra de le construire.
Ce sont 2 aspect radicalement différent.

je pense comprendre a quel niveau le courant ne passe pas
eh ben la table "categorie_croisees" servira aussi a construire le menu, c'est pour ca que j'arrive pas a avaler cette solution
disons que la categorie "Luminaire" dont l'id_cat=7 se trouve dans "Salle de bain" id_cat=4 et "Salon" id_cat=3
si j'ai bien compris:
la table "categorie": id_cat (7: Luminaire) -> id_parent (4: Salle de bain)
et dans la table "categorie_croisees": id_cat (7: Luminaire) -> id_cat_croisee(3: Salon)

ces 2 lignes sont dans 2 tables differentes.
Pour afficher le menu j'aurai besoin de requeter les 2 tables afin d'afficher toutes les rubriques y compris celles croisees....

donc quand tu dis : "Non, la table "categorie_croisees" n'est absolument pas un menu" c'est faux puisque le menu contient aussi ces categories croisees...

J'espere vraiment que tu comprends mieux ma problematique...

[RunCodePhp]

donc quand tu dis : "Non, la table "categorie_croisees" n'est absolument pas un menu" c'est faux puisque le menu contient aussi ces categories croisees...

Ton menu c'est avant tout des catégories, et même essentiellement ce qui ce trouve dans la table catégories.
Les croisements ce sont des pièces rapportées, donc des éléments à part.
S'il n'y pas de catégorie, il ne sera pas possible de créer de croisements, l'inverse oui.
De même qu'il n'est pas obligatoire que toutes les catégories soit croisées avec d'autres.
Ce n'est pas du tout la même chose.

Coté relation c'est 0,n donc 1 catégorie peu donner lieu à 0 ou plusieurs catégories croisées.
Et bien là, la règle est simple : Ces éléments doivent se trouver dans une autre table, et ça se traduira par des lignes : 1 ligne = 1 croisement.
Ce n'est pas moi qui veut ça, c'est la base même de la conception de BDD.
Que te dire d'autre sinon de me baser la dessus ?


Pour les produits c'est la même chose, il sera absurde de vouloir ranger les croisements de produits dans la même table "produits" en rajoutant 1 ou plusieurs champs.
Là encore ce sont des éléments rapportés, les relations sont les mêmes (0,n) autre table par conséquent.

A savoir d'ailleurs que ce problème est exactement le même que celui des langues, à un tout petit détail près.
- 1 produit donne lieu à 1 ou plusieurs contenu linguistiques (leur nom pour plusieurs langues).
Et bien ça donne lieu à 1 table pour les contenus linguistiques : 1 ligne = 1 nom (pour 1 langue)
Relation 1,n. Le détail c'est qu'il faut au moins 1,n (et non pas 0,n) car s'il n'y a pas au moins 1 nom (1 langue) il sera impossible d'afficher quoi que ce soit.


Désolé, mais de mon coté c'est une évidence, et je ne me vois faire autrement par exemple.


Mais encore une fois, si tu souhaite faire selon ton schéma, et bien adopte le.

[tse_jc]

Bonjour à tous. Je suis nouveau sur le forum et mon boulot étant l'etude/conception/réalisation d'applications, j'ai lu ce sujet attentivement vous pouvez vous en douter.

Je vais essayer d'épauler un peu RunCodePhp sur ce coup, car je pense que ca lui fera du bien

Donc redah75, permets moi pour commencer de reprendre ce que tu viens de dire

Pour afficher le menu j'aurai besoin de requeter les 2 tables afin d'afficher toutes les rubriques y compris celles croisees....

donc quand tu dis : "Non, la table "categorie_croisees" n'est absolument pas un menu" c'est faux puisque le menu contient aussi ces categories croisees...

Plusieurs choses à dire:
- Je ne vois pas en quoi requeter plusieurs tables pose un problème, ce n'est pas en requêtant qu'une seule table que tu feras grand chose.

- Si tu fais un menu qui affiche tous tes produits, serais-tu prêt à dire qu'il est faut également de dire que la table produits n'est pas un menu sous pretexte que ton menu contient des produits? Ton menu reste un menu et il représente uniquement une logique de présentation de tes données qui n'a strictement rien à voir avec la façon dont tes données sont hierarchisées en interne de ton applicatif. Ton menu est quelque chose de strictement subjectif et relatif et relève de ta stratégie commerciale, alors que la structure de tes données est par contre rationnelle, logique et optimisée à ton cahier des charges applicatif. Changer la façon de présenter les données ne change en rien la nature et la façon dont tes données sont structurées (bien qu'elle peut l'influencer dans un soucis d'optimisation).

- J'ai l'impression que pour que "tu puisses être en paix avec toi même" qu'il te faille une table par fonction applicative. Ca relève de l'utopie. Par contre il te faudra une requête spécifique à chaque fonction de ton applicatif (qui peut créer une table temporaire il est vrai). Sache qu'une requête de plusieurs centaines de lignes ca existe et ca peut être très performant même.

voilà

[redah75]

Bonjour et bienvenu tse_jc dans cette discussion sans fin, tu n'as pas idee dans quoi tu t'enfonce )

Plusieurs choses à dire:
- Je ne vois pas en quoi requeter plusieurs tables pose un problème, ce n'est pas en requêtant qu'une seule table que tu feras grand chose.

ca ne me pose pas de probleme, j'ai deja requete une dizaine de table en une requete, mais ce qui me gene ici c'est le fait de stocker la meme info dans 2 table differentes:
1ere info & 1ere table: "Luminaire" qui fait parti de "Salle de bain"
2e info & 2e table: "Luminaire" qui fait parti de "Salon".

vous savez, cette bdd me hante tellement que j'en ai revé hier soir pdt mon sommeil

je suis desolé RunCodePhp si je ne comprends toujours pas trop ce que tu m'explique. peut etre que c'est pas ton schema que j'ai en tete, d'où ce mal entendu!!
je vais essayer de clarifier la situation au maximun pour vite en finir et vous liberer
RunCodePhp: est ce que la solution que tu me preconises est bien celle ci???

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
Table categories
id_cat | id_parent
--------------------------
1      | 0 // Maison
2      | 0 // Mode
3      | 1 // Maison -> Salle de bain (1er croisement, 1 seul croisement)
4      | 1 // Maison -> Salon (1er croisement, 1 seul croisement)
5      | 3 // Maison -> Salon -> Luminaire (1er croisement, 2 croisements)
6      | 3 // Maison -> Salon -> Tables (1er croisement, 1 seul croisement)

Table categories_croisements
id_cat | id_cat_croisee
--------------------------
5      | 4 // Maison -> Salle de bain -> Luminaire (2e croisement)

Table categories_traductions
id_cat | lang | libelle
--------------------------
1      | fr   | Maison
2      | fr   | Mode
3      | fr   | Salon
4      | fr   | Salle de bain
5      | fr   | Luminaire
6      | fr   | Tables
7      | fr   | Luminaire
...

cette simulation illustre la cas où "Luminaire" (id_cat 5) se trouve dans la rubrique "Salon" (id_cat 3) et "Salle de bain" (id_cat 4)

je poserai question par question pour ne pas trop se meler les pinceaux. selon ta reponse, je te poserai d'autres questions...

Bonne soiree et merci encore une fois pour vos efforts. on va y arriver

[RunCodePhp]

Je vais essayer d'épauler un peu RunCodePhp sur ce coup, car je pense que ca lui fera du bien

Tu peux, aucun problème.
On va finir par se comprendre, surtout.

peut etre que c'est pas ton schema que j'ai en tete, d'où ce mal entendu!!

Ca se peu que cela tournait à un dialogue de sourd.
C'est surement du faite que tu change les noms sans cesse, ce qui fait qu'on ne sait plus qui correspond à quoi.

Cette fois, tu utilise le même schéma que j'ai donné, les même noms, les mêmes valeurs, et c'est bien plus clair. (c'est important d'utiliser les bons termes).

Donc cette fois tout est Ok (à quelques détails près).

Table categories
id_cat | id_parent
5 | 3 // Maison -> Salon -> Luminaire (1er croisement, 2 croisements)

Pour cette ligne, ce n'est pas le 1er croisement, absolument pas, c'est juste une nouvelle catégorie (Luminaire), une vrai catégorie à part entière.
C'est juste que celle ci (son ID unique 5) est lié à une autre catégorie (son parent) 3.
On pourra lier de la même façon des produits à cette catégorie 5.

Table categories_croisements
id_cat | id_cat_croisee
--------------------------
5 | 4 // Maison -> Salle de bain -> Luminaire (2e croisement)

Non, ceci est le 1er croisement, c'est d'ailleurs la 1ère ligne.
Une 2ème ligne avec le même id_cat (5) par exemple sera le 2ème croisement, et ainsi de suite.
Donc chaque ligne équivaut à 1 croisement, après tout dépend de la valeur du id_cat.
J'insiste sur le faite que coté Bdd, il faudra mettre comme clé primaire les 2 champs : PRIMARY KEY (id_cat, id_cat_croisee).
Ceci évitera de créer des doublons, même en le faisant directement dans la Bdd (PhpMyAdmin par exemple).
En tout cas, il ne faut pas de champ auto_increment ici (ce qui se voit très souvent, et à tord)

Table categories_croisements
id_cat | id_cat_croisee
--------------------------
5 | 4 // Maison -> Salle de bain -> Luminaire (1e croisement)
4 | 5 // Maison -> Luminaire -> Salle de bain (2e croisement)

On peu aussi proposer l'inverse, ce n'est pas obligé, mais possible.
Mais attention à une éventuelle boucle infinie dans son code dans ce cas là (c'est ce que je disais quelques post plus haut).

Table categories_traductions
id_cat | lang | libelle
--------------------------
1 | fr | Maison
2 | fr | Mode
3 | fr | Salon
4 | fr | Salle de bain
5 | fr | Luminaire
6 | fr | Tables
7 | fr | LuminaireA supprimer

Il n'y a pas de id_cat 7 dans la table "categories", cette ligne ne doit pas y être, il n'y a pas besoin de créer 2 fois Luminaire, elle existe déjà, c'est le id_cat 5.


Je ne sais pas si de ton coté tu le perçois, mais quand on utilise les bons termes, les choses deviennent plus clair.
-> La table "categories_croisements" regroupe les croisements de catégories.
-> Le champ id_cat désigne la catégorie à croiser
-> Le champ id_cat_croisee désigne la catégorie vers laquelle elle sera croisée.


Mais n'oubli pas qu'il y a aussi des croisements possible sur l'autre table existante : categories_produits :

Code :

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

1
2
3
4
 
id_cat | id_prod
5        | 2
4        | 2

Le fait qu'il y ait 2 produits en commun fera qu'il sera possible de récupérer la ou les autres catégories.

Les 2 modèles donnent des résultats différents, du moins, ils provoquent des phénomènes différents.
Celui qui provoque le moins de phénomène est celui de la table séparée, c'est plus "carré".
Donc ça se peut qu'il faille utilise soit l'un, soit l'autre, voir même les 2.

je suis desolé RunCodePhp si je ne comprends toujours pas trop ce que tu m'explique.

Mes dernières explications, les relations 0,n, ou relations 1,n sont à la base d'une conception de Bdd.
Le terme exacte est : Les cardinalités, et ceci vient de Merise (pour l'aspet technique).

Toutes les données ont des relations entre elles (à part rares exceptions, ça arrive).
Si tu pose clairement les relations (ou cardinalité), ceci te permettras de structurer la Bdd, créer les tables, et aussi de désigner les noms des tables et des champs (utiliser les bon termes, c'est important), et de définir les clés primaires et clés étrangères.

Absolument tout repose sur ces relations, tout part de là.

[tse_jc]

Bonjour,

ca ne me pose pas de probleme, j'ai deja requete une dizaine de table en une requete, mais ce qui me gene ici c'est le fait de stocker la meme info dans 2 table differentes:

Mis à part ce qu'à pu relever RunPhp, c'est là à mon humble avis que tu te trompes: Ce n'est pas la même info. Il faut considérer en pratique les catégories de la table "categories" comme des catégories primaires et les catégories de la table "categories_croisees" comme des catégories secondaires à vocation temporaire bien qu'elle puissent être permanentes.
Ce schéma est peut être plus facile à comprendre dans une relation produit/categorie que categorie/categorie un peu plus abstrait de prime abord.

Donc si je ramène cela à un produit, prenons un cas simple: la crème chantilly. Sa catégorie primaire pourrait être "Produit laitier". Cette catégorie est sa catégorie primaire : pas question de la changer car c'est la catégorie qui la représente le mieux et où tout le monde ira la chercher. Par contre, le jour où je désire vendre des fraises en masse, et que je désire booster mes ventes, je peux créer momentanément un croisement de catégorie avec la catégorie fruits pour proposer ma crème chantilly avec mes fraises. Il est donc normal de stocker cette info ailleurs que dans la table qui défini la catégorie primaire de mon produit, car elle n'a pas cette vocation. Je te laisse faire l'analogie de catégorie à catégorie.

PS: excuse moi RunPhp si en disant cela si j'utilise un vocabulaire à vocation didactique plutôt que technique comme tu l'as si bien fait.