Discussion :

[bigs3232]

* Bonjour, *

j'ai des produits avec des références suivantes

ref-1,ref-2,ref-3,ref-4,ref-5,ref-6,ref-7,ref-8,ref-9,ref-10

ces références sont compatibles entre eux

le client peut choisir ref-1 ou ref-2 ça marche quand même
j'aimerais que quand client tape ref-1 ça affiche les 9 autres références compatibles (ref-2 à ref-10)
je pensais créer une table avec 3 champ
id_produit, ref, ref_compatible

l'inconvénient c'est que pour une ref-1 je dois saisir 9 lignes dans le champ ref_compatible
pour une référence peut avoir une cinquantaine de référence compatibles
si j'ai 10 000 références j'aurai la table à 500 000 lignes ce qui pour moi ingérable
j'espère me suis bien fait comprendre

il y a une solution de faire autrement ?
merci d'avance

[escartefigue]

Bonjour,

Ne répetez surtout pas les colonnes dans votre table !
Construisez une relation réflexive comme suit :

PRODUIT (id, reference, nom, etc...) 0,n --- Compatible --- 0,n PRODUIT

Le modèle logique généré donnera 2 tables :
PRODUIT (id, reference, nom, etc...)
COMPATIBLE (id, id_2)

[bigs3232]

merci pour votre réponse rapide .je n'ai pas bien compris .id_2 doit contenir la liste des ref-1,ref-2 ect.. en une seule ligne ?
un petit exemple m'aiderais grandement et dans la table PRODUIT il faut mettre quoi dans le champ reference

[escartefigue]

Exemple : le produit d'identifiant 10, est compatible avec les produits dont les identifiants sont 05, 12 et 28
Vous aurez dans la table PRODUIT une ligne pour chaque identifiant, avec sa référence, son nom etc...
Vous aurez dans la table COMPATIBLE, pour le produit d'ID=10, toutes les lignes suivantes :

• 10, 05
• 10, 12
• 10, 28

Autant d'occurrences dans la table COMPATIBLE qu'il y a de produits compatibles avec le produit d'ID n°10
S'il n'y a rien dans la table COMPATIBLE pour le produit d'ID=10, c'est que aucun produit n'est compatible avec le 10
C'est la seule façon de modéliser proprement votre besoin

[bigs3232]

merci ca revient au meme problème que j'ai au début
si l'id 10 a 50 reférences compatibles donc il y a 50 lignes a saisir dans la table compatible
et comme ces 50 memes références son aussi compatibles entre eux donc j'aurais 50*50 lignes a saisir dans la table compatible

[bigs3232]

apparemment j'ai impression qu'il n'y a qu'une solution .ma table compatible va être énorme mais bon je continue ma réflexion sur le sujet

[aieeeuuuuu]

Bonjour,

et comme ces 50 memes références son aussi compatibles entre eux donc j'aurais 50*50 lignes a saisir dans la table compatible

est-ce toujours le cas ?
est-ce qu'un produit A peut être compatible avec les produits B et C sans que B soit compatible avec C ?

Vous pourriez introduire la notion de groupe de produits afin d'éviter toutes ces répétitions : les produits appartiennent à un (ou plusieurs ?) groupe, et tous les produits d'un groupe sont compatibles entre eux.

[al1_24]

Tu peux déjà commencer par n'enregistrer dans ta table compatible que les tuples pour lesquels id est inférieur à id_2. Cela divisera par deux le nombre de lignes.
Mais alors, me diras-tu, comment enregistrer les autres compatibilités ?
En inversant simplement l'ordre des colonnes.
Et pour connaître la liste de toutes les compatibilités d'un produit ?
En interrogeant une vue composée de l'union entre la table et son équivalent avec les colonnes inversées...

Mise en oeuvre :
Le produit 10 est compatible avec les produits 5, 8, 12 et 14.

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
insert into compatible(id_2, id_1) values (10,  5);
insert into compatible(id_2, id_1) values (10,  8);
insert into compatible(id_1, id_2) values (10, 12);
insert into compatible(id_1, id_2) values (10, 14);
 
create view lst_compat
as  (   select  id_1, id_2  from compatible
    union all
        select  id_2, id_1  from compatible
    )
;
select  id_1, id_2
from    lst_compat
where   id_1 = 10
;
id_1    id_2
10       5
10       8
10      12
10      14
 
select  id_1, id_2
from    lst_compat
where   id_1 = 8
;
id_1    id_2
 8      10

[bigs3232]

merci pour tous de vous pencher sur mon problème
pour répondre à aieeeuuuuu =>oui ils sont compatibles entre eux dans 99% des cas
l'idée de al1_24 est intéressante
je ne sais pas ce que vous en pensez si je fais çà:
champ id et champ list_id_comptible

id list_id_comptible
1 1!2!3!4!5
2 1!2!3!4!5
3 1!2!3!4!5
4 1!2!3!4!5!6
5 1!2!3!4!5

si le client cherche 4 il voit la liste des compatibles 1 2 3 4 5 6
j'ai que 5 lignes d'enregistrement au lieux de 25

[bigs3232]

meme si ma solution n'est pas la plus propre mais je crois que c'est la plus simple et moins de lignes d'enregistrement
si j'ai 100 references compatibles entre eux j'aurais 100 ligne et pas 100 *100 lignes.
par contre j'aimerais bien connaitre le défault de cette méthode
merci pour votre aide tres précieux avant de me lancer à la production

[aieeeuuuuu]

si le client cherche 4 il voit la liste des compatibles 1 2 3 4 5 6

Oui, mais s'il veut simplement le moins cher par exemple ? comment ferez vous ? imaginez la tête de la requête qui devra parser la deuxième colonne pour en extraire les id afin de pouvoir faire une jointure sur la table des produit pour obtenir le prix...

Quant à l'insertion, il ne me semble pas spécialement plus simple de concaténer les données pour les insérer que d'insérer directement plusieurs lignes.

bref, c'est une fausse bonne idée. pour vous en convaincre, on peut mener le raisonnement plus loin : de la même manière, vous pourriez stocker toutes vos données dans une seule table d'une seule colonne et une seule ligne. A la première requête, vous verrez très vite les "défauts" de cette modélisation.

[bigs3232]

intéressant merci aieeeuuuuu
pour vous répondre:
1-insertion est tres simple depuis un fichier excel avec ces 2 colonnes

1 1!2!3!4!5
2 1!2!3!4!5

je fais afficher la liste des compatible
1 2 3 4 5
et si le client clique sur 1 ca affiche les liste des compatible de 1
avec une select from pour trouver 1 et un explode en php pour recupérer le champ id_compatible et non une requete sql sur le champ id_compatible
pour le prix le moins cher c'est pas un souci non plus car 1,2,3,4,5 a une clé avec une autre table produit pour le prix
je reconnais que c'est chaud mais bon je cherche la faille possible de cette méthode et les solutions adaptées
Une autre solution c'est une fois le select fait , on fait une deuxieme recherche sur le champ id_compatible avec une expression régulière par exemple pour trouver ce que l'on veux .mais je ne sais pas si le temps d'exécution sera plus rapide en expression régulière
ce systeme est valable si le contenu du champ id_compatible n'est pas trop grand
je ne pas du tout expert mais j'ai besoin d'avis de ceux ayant plus d'expérience que moi dans ce domaine

[aieeeuuuuu]

1-insertion est tres simple depuis un fichier excel avec ces 2 colonnes

Oui, mais elle sera toute aussi simple avec un fichier excel sous la forme

1 - 1
1 - 2
1 - 3
...

(en plus, je pense que ce sera plus lisible. Pensez aussi que vos id ne seront pas toujours sur une seul digit comme dans les exemples ici. l'utilisateur risque d'être un peu perdu en voyant 28475!4485739!364!5768!48596. Par ailleurs, comment afficherez vous les informations complémentaires (comme le prix) ? bref, ça reste une question de gout et on dérive du sujet initial.

pour le prix le moins cher c'est pas un souci non plus car 1,2,3,4,5 a une clé avec une autre table produit pour le prix

Certes, mais :
Il vous sera impossible d'assurer l'intégrité des données, puisque vous ne pourrez pas déclarer de contrainte d'intégrité référentielle. Vous risquez donc de vous retrouver avec des id de produit qui n'existent pas/plus. Et soyez sûr que ce cas arrivera un jour ou l'autre.
Pour les même raisons, il vous sera impossible de poser un index utile sur cette deuxième colonne, donc une grosse perte de performance.
De plus, l'optimiseur ne pourra pas estimer correctement les cardinalités résultantes de ce type de jointure, ce qui mènera à des plans de requête inefficaces.

Une autre solution c'est une fois le select fait , on fait une deuxieme recherche sur le champ id_compatible avec une expression régulière par exemple pour trouver ce que l'on veux .mais je ne sais pas si le temps d'exécution sera plus rapide en expression régulière
ce système est valable si le contenu du champ id_compatible n'est pas trop grand

Donc deux requêtes au lieu d'une seule, avec un aller/retour au client et un traitement coté client entre les deux... Là aussi, soyez sûr que les performances en pâtiront.

Concernant votre crainte d'une table contenant beaucoup de lignes, soyez rassuré : un SGBDR sait très bien gérer un grand nombre de lignes et faire des jointures, c'est son job après tout. C'est plus la volumétrie globale qu'il faut prendre en compte et sur ce point faisons un rapide calcul :
- Si on part sur une base arbitraire de 50 000 produits, on peut stocker l'id dans un SMALLINT (2 octet), et il faut +/- 5 caractères pour les stocker dans une colonne de type VARCHAR (plus un caractére de séparation dans le modéle que vous proposez).
- Admettons également que chaque produit est compatible avec dix autres produits en moyenne.
Avec votre méthode, cela fera donc 2 octets pour la première colonne + 10 X (5 + 1) + 1 soit 63 octets
Avec la méthode classique (une ligne par couple de produits compatibles), nous aurons 10 X (2 + 2) soit 40 octets

Bien sûr ce calcul peut varier en fonctions du nombre moyen de digits par id de produit et du nombre de produits compatibles entre eux, mais dans ces conditions, on voit que l'avantage est à la méthode "classique".

[Artemus24]

Salut à tous.

Pour une fois, nous avons un sujet intéressant à débattre.

ces références sont compatibles entre eux

C'est le terme "compatible" que je ne comprends pas trop. Je m'explique sur ce point :

1) vous parlez des produits.
Ce que je comprends, c'est l'association d'une liste de référence vis-à-vis des références. Autrement dit, en terme de relation, j'exprime ceci :

prod 1 <-- ref1, ref2, ref3

Mais si vous avez un autre produit, avez-vous cela ?

prod 2 <-- ref2, ref5

C'est-à-dire que la "ref2" est commune aux produits "prod1" et "prod2".
Est-ce un cas de figure qui peut-arriver ?

2) si la référence se suffit à elle-même, c'est-à-dire que nous avons une liste de références qui sont associées entre-elle.
En quoi la solution de Escartefigue ne vous convient pas ?
C'est à peu de chose près la solution de aieeeuuuuu, quand il parle de définir un groupe.
A moins que vous n'avez pas compris en quoi consiste la relation récursive dont parle Escartefigue ?

merci ca revient au même problème que j'ai au début

Pas exactement, car vous gardez la souplesse des relations dans le modèle d'Escartefigue.
En effet, que ce soit un groupe ou un identifiant, si vous avez cent références, vous aurez cent lignes à insérer.

et comme ces 50 mêmes références son aussi compatibles entre eux donc j'aurais 50*50 lignes a saisir dans la table compatible

Non !

Car ce qui fait le lien entre vos différentes références, c'est l'identifiant !
Dans l'exemple donnée par Escartefigue :
10, 05
10, 12
10, 28
l'identifiant ici est 10. Donc si vous avez 50 références en relations, vous aurez 50 lignes dans votre table des compatibles.

est-ce qu'un produit A peut être compatible avec les produits B et C sans que B soit compatible avec C ?

C'est ce que j'ai aussi soulevé comme interrogation.
En fait, plusieurs questions se posent sur le modèle de relation entre les produits et les références.

En terme de mathématique, on parle soit de :

a) relation d'équivalence : https://fr.wikipedia.org/wiki/Relati...3%A9quivalence
Autrement dit, si ref2 <-- ref1 on a nécessairement ref1 <-- ref2.
Est-ce le cas ?

b) relation d'ordre : https://fr.wikipedia.org/wiki/Relation_d%27ordre
Autrement dit, si ref <-- ref1, vous n'avez pas nécessairement ref1 <-- ref2.

Faire la distinction entre ces deux types de relations impliquera des solutions différentes.

P.S.: ne vous inquiétez pas trop sur comment remplir votre table "compatible".
Je veux vous fournir une procédure stockée qui réalisera le remplissage de la table "compatible" à partir d'un existant.

@+

[bigs3232]

Merci pour vos réponses

Donc deux requêtes au lieu d'une seule, avec un aller/retour au client et un traitement coté client entre les deux... Là aussi, soyez sûr que les performances en pâtiront

non une seule requete avec REGEXP en sql sur le deuxième champ comme par exemple

Code :

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

select * from  TABLE where champ1= and champ2 REGEXP;

- Admettons également que chaque produit est compatible avec dix autres produits en moyenne.
Avec votre méthode, cela fera donc 2 octets pour la première colonne + 10 X (5 + 1) + 1 soit 63 octets
Avec la méthode classique (une ligne par couple de produits compatibles), nous aurons 10 X (2 + 2) soit 40 octets

vous m'avez donner une idée?créer une autre table de 2 champ.et 1a servira de jointure

Code :

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

1
2
 
1a  1!2!3!4!5

au lieu d'avoir çà

Code :

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

1
2
3
4
5
6
 
1 1!2!3!4!5
2 1!2!3!4!5
3 1!2!3!4!5
4 1!2!3!4!5!6
5 1!2!3!4!5

j'aurais

Code :

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

1
2
3
4
5
6
 
1 1a
2 1a
3 1a
4 1!2!3!4!5!6
5 1a

pour répondre à Artemus24

C'est-à-dire que la "ref2" est commune aux produits "prod1" et "prod2".

oui ca arrive souvent

est-ce qu'un produit A peut être compatible avec les produits B et C sans que B soit compatible avec C ?

non les compatibilités sont automatiquement dans les deux sens
j'ai remarqué que pour chaque produits je peux avoir jusqu'à 100 produits compatibles .donc j'ai intérêt à bien réfléchir en amont

[Artemus24]

Salut à tous.

non les compatibilités sont automatiquement dans les deux sens

J'avais un doute, donc merci pour cette précision.

Pourquoi la solution proposée par Escartefigue ne vous convient-elle pas ?
Soit par exemple les deux groupes suivants :
--> ref1, ref3, ref5, ref7
--> ref2, ref4, ref6, ref8

Le remplissage de la table des "lien de références " donne :

Code :

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

1
2
3
4
5
6
7
8
9
10
Id   Reference  Lien
---  ---------  ----
 1   ref1       Null
 2   ref2       Null
 3   ref3       1
 4   ref4       2
 5   ref5       1
 6   ref6       2
 7   ref7       1
 8   ref8       2

Et pour retrouver la liste de toutes les références à partir d'une référence donnée :

Code :

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

1
2
3
4
5
6
select      group_concat(t1.reference, ",")
      from  `tablien` as t1
inner join  `tablien` as t2
        on  t2.lien      = t1.id
       and  t2.reference = 'ref5'
  group by  t1.id;

@+

[bigs3232]

merci artemus32 ainsi que les autres intervenants,j'ai besoin de réfléchir à toutes vos idées avant de répondre

[bigs3232]

finalement c'est très intéressant votre idée Artemus24
je ne savais pas qu'on peut faire une requete sql sur une même table avec inner join ou left join.cette notion de produits dans un groupe ,je l'ai déjà utilisé pour classer mes produits dans plusieurs groupes ou simplement catégories.on peut faire les requetes pour chercher, pour modifier la liste (enlever ou ajouter) et pour insérer çà a l'air pas mal

[Artemus24]

Salut bigs3232.

finalement c'est très intéressant votre idée Artemus24

Rendez à César ce qui appartient à César ...

Non, ce n'est pas mon idée, mais celle d'Escartefigue qui l'a exprimé dans le message #2. Je pense que vous n'avez pas compris son idée quand il l'a exposée.

je ne savais pas qu'on peut faire une requête sql sur une même table avec inner join ou left join.

Qu'est-ce qui vous empêche de le faire ?

La table en question est structurée comme un arbre. Au sommet de l'arbre, la racine et en bas, les feuilles.
Chaque feuille pointe sur un nœud qui dans votre cas est la racine.
La racine est celle qui possède NULL dans la colonne lien.

cette notion de produits dans un groupe ,je l'ai déjà utilisé pour classer mes produits dans plusieurs groupes ou simplement catégories.

C'est une autre façon de structurer vos données afin de les organiser sous la forme d'un arbre.

on peut faire les requêtes pour chercher, pour modifier la liste (enlever ou ajouter) et pour insérer çà a l'air pas mal

Il faut encore maîtriser ce genre de manipulation. Ici votre arbre est relativement simple !

@+

[bigs3232]

encore merci Artemus24.oui Escartefigue a lancer l'idée mais je ne vois pas par la suite comment utiliser les requetes sql pour filtrer mes produits compatibles .grace à votre requete j'ai compris son potentiel de cette méthode.Question
si exemple ref5 appartient à id 1 et id 2 cà poserait des problèmes pour la requete SQL ?
en gros s'il y a pas mal d'intersection entre groupe id 1 et groupe id 2 , la requete SQL serait simple?