Discussion :

[talvins]

Bonjour,

j'aimerais pouvoir, aussi proprement que possible, sélectionner les lignes d'une table dont la valeur d'un champ appartient à un ensemble de valeurs.

Moins succinctement : j'ai une table d'objets (pendule, livre, dvd, tee-shirt...), avec divers infos, dont un champ qui indique l'origine de l'objet.
J'ai une autre table (dans mon idée, mais ce n'est peut-être pas ce qu'il y a de mieux) contenant des noms de groupe dans une colonne et la liste des origines correspondantes dans une autre.
Par exemple :
groupe->'grandes villes' | origines->'paris, nice, marseille, lyon'
groupe->'paca' | origines ->'marseille, toulon, cannes, nice'

Je souhaite pouvoir afficher les objets appartenant, disons, aux 'grandes villes' (voire à plusieurs groupes).

Sachant que les groupes sont modifiés souvent (donc pas bonne idée de mettre le groupe directement dans la table de l'objet), est-ce que l'idée de la seconde table est bonne ?
Dans ce cas, quelle serait la requête la plus propre et rapide (en terme vitesse de traitement) à faire ?
Sinon, qu'est-ce que je peux faire de mieux ?

Merci.

[Swoög]

Salut !

cela dépend de la structure de tes tables... ça serait possible d'avoir un rapide aperçu ?

[talvins]

Tout ce qu'il y a de plus simple :

CREATE TABLE objets (
ref SMALLINT UNSIGNED NOT NULL PRIMARY KEY,
nom CHAR(30) NOT NULL,
descr BLOB,
entree TIMESTAMP NOT NULL,
sortie TIMESTAMP,
lieu CHAR(40) NOT NULL,
familles SET('a','b','c','d','e') NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

Je peux utiliser SET pour les familles car, là, il s'agit de catégories fixes.
Mais, si un objet est à Paris, aujourd'hui il appartient à la catégorie 'grandes villes', 'villes touristiques' et 'ville de gauche' mais demain il pourra également appartenir à la catégorie 'villes très polluées' et 'villes de droite' (et donc plus à 'ville de gauche').

La table des catégories n'existe pas puisque je ne sais pas encore quelle méthode utiliser.

J'ai également pensé à faire traiter ça par PHP en utilisant un ARRAY_MERGE puis un IN_ARRAY mais je pense que ce sera moins rapide (?).

[Swoög]

donc, en fait, si je te comprend bien, ce que tu veux, c'est trouver un schéma de table pour pouvoir établir les relation :

objet dans un lieu [ce que fait ta table actuelle]
lieu dans une catégorie

et avoir la requête pour pouvoir obtenir la relation
objet dans une catégorie

sachant que la relation objet/lieu est en n<=>1 (plusieurs objets pour un lieu, mais un seul lieu par objet)
et la relation lieu/catégorie et en n<=>n (plusieurs lieux dans une catégorie, et plusieurs catégories pour un lieux)

C'est bien ça ?

[talvins]

Exactement.

[Swoög]

ok

alors, déjà perso, je te conseillerais (mais c'est tout personnel hein, c'est juste que je trouve que c'est plus pratique ^^)
de faire deux tables (je connais pas la syntaxe MySQL pour le générer mais je vais te donner le schéma ^^ :

Code :

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

1
2
3
lieux :
id (entier) PK, en auto-incrémente
nom (texte, unique de préférence)

Code :

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

1
2
3
4
 
catégories :
id (entier) PK, en auto-incrémente
nom (texte, unique de préférence)

comme ça, tu as la liste de tous les lieux et catégorie, et c'est meilleur pour les performances de stocker des entiers (tailles fixes) à des chaînes

ensuite, une première table de liaison, qui répertorie la liaison lieux<=>catégorie :

Code :

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

1
2
3
4
 
lieu_cat :
id_cat (entier, FK sur catégories.id)
id_lieu (entier, FK sur lieux.id)

puis modifier un peu la table objet pour avoir ce type de table :

Code :

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

1
2
3
4
5
6
objets:
id (entier) PK, en auto-incrémente
.
. (autres champs)
.
id_lieu (entier, FK sur lieux.id)

Je pense que tu vois la structure des tables

ensuite, pour avoir la relation objet<=>catégorie :

Code :

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

1
2
3
4
SELECT O.id AS obj_id, LC.cat_id
FROM objets AS O
<div style="margin-left:40px">INNER JOIN lieu_cat AS LC
<div style="margin-left:40px">ON O.lieu_id = LC.lieu_id</div></div>

ensuite, tu peux rajouter des champs de objets si tu veux, et pour rajouter le nom de la catégorie, il te faut faire une petite jointure suppélementaire :

Code :

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

1
2
3
4
5
6
SELECT O.id AS obj_id, C.name AS cat
FROM objets AS O
<div style="margin-left:40px">INNER JOIN lieu_cat AS LC
<div style="margin-left:40px">ON O.lieu_id = LC.lieu_id
INNER JOIN catégories AS C
<div style="margin-left:40px">ON LC.cat_id = C.id</div></div></div>

S'il y a un point que tu ne comprends pas, n'hésite pas à demander

[talvins]

Merci de m'avoir fourni une solution.

Bon, déjà je vire tes aliases qui rendent le tout assez illisible pour moi , ensuite je rétablis les id_lieu et id_cat qui deviennent cat_id et lieu_id (à moins que j'ai loupé une subtilité SQL).

Première remarque : tu crées une table lieux, ce qui rendra peu pratiques (et plus lents) les INSERT et UPDATE d'objets car il faudra que je fasse d'abord que je trouve le lieux.id correspondant au lieux.nom.

Seconde remarque : pourquoi créer un index dans la table objet alors que j'ai déjà objets.ref ?

Troisième remarque : si j'ai bien compris, ma table lieu_cat sera composée de couple de valeurs. La lisibilité sera donc pas terrible.

Je ne sais pas si j'ai tout bien saisi mais si c'est tel que je l'ai décrit, c'est un peu trop abstrait pour rendre les modifs aisées (pas au niveau technique). Bon, tu me diras, si je demande de l'aide, c'est que je ne vois pas grand chose, à part la version PHP (qui serait claire, mais peu optimisée je pense), donc faudrait peut-être que je me taise

Mais si jamais tu as qq chose de plus 'lisible', ce serait pas mal.

Dans tous les cas, merci pour ta réponse.

[Swoög]

alors, pour l'index sur Objet, j'ai juste pris id pour indiquer que c'est quelque chose qui permet d'identifier un objet de manière unique, tu peux utiliser ref sans problème...

ensuite, pour les alias, ils sont au contraire là pour rendre une requête plus lisible... perso j'ai du mal quand ils sont pas là, y'a du texte de partout, enfin, si te préfère sans, je vais te donner une version sans...

enfin, pour les tailles, tout dépend comment tu gères cela, mais personnellement, d'habitude quand j'ai des tables de ce genre là, la modification des données se fait via des <select> générés automatiquement avec des options du style

Code :

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

<option value="{ID}">{NAME}</option>

, ce qui fait que ce n'est pas le nom, mais bien l'id qui sera envoyée à la soumission du formulaire

ensuite, pour ce qui est de ne stocker que des chiffres, c'est pour une question de performances, ta table de liaison sera plus performantes et il y aura moins de risques d'erreurs si tu stockes les id que les noms (on se trompe beaucoup plus facilement sur un nom...)

les tables de données n'ont pas pour vocation d'être facile à lire, mais de représenter des données et des relations entre les données qui soient sotckées de façon optimisée... c'est ensuite dans les requêtes de selection qu'il faut s'occuper des détails d'affichage...

Bon... ensuite, si tu veux te passer de l'abstraction que j'avais mis... sans problème, la table lieux, et la table catégorie deviennent inutiles, et les tables se transforment en :

Code :

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

1
2
3
lieu_cat :
cat
lieu

Code :

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

1
2
3
4
5
6
objets:
id (entier) PK, en auto-incrémente [ref si tu veux]
.
. (autres champs)
.
lieu

et les requêtes [enfin la requête puisqu'il n'y en a plus qu'une] (sans alias cette fois, tu peux remplacer objets.id par objets.ref c'est juste une façon de noter la colonne)

Code :

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

1
2
3
4
SELECT objets.id, lieu_cat.cat
FROM objets
<div style="margin-left:40px">INNER JOIN lieu_cat
<div style="margin-left:40px">ON objets.lieu = lieu_cat.lieu</div></div>

[talvins]

Pour les aliases, c'est bon, je pouvais les enlever moi-même

Ok pour les autres remarques.
Tu as tout à fait raison quant aux id numériques issus de <OPTION>. J'avais même oublié que je faisais une conversion num->alpha !
Mais le problème, c'est que cette base n'est utilisée qu'en lecture. Sa modif est faite via un import où les villes sont en texte. Mais, au vu de ce que tu me dis, je pense qu'il serait effectivement préférable que je traduise ces villes dès leur import.

Merci pour ton aide.