Je fais un système de gestion de docs.
 
Pour chaque doc on a : titre, nom du fichier, description, categories.
Les catégories ont un numéro et elles sont gérées dynamiquement.
 
Mon pb est qu'un doc peut appartenir à pls catégories donc je ne peux faire de jointure.
Comment dois-je organiser cela ?
 
Un champs VARCHAR dans lequel je mettrais les n° de cat du doc séparés de "|" (ex : 1|7|8). Ensuite pour afficher en fonction de la cat on fait un categories LIKE '1'. Mais c'est un peu nul ! Surtout que LIKE '1' retourne aussi les docs des cats 10, 11, etc.

Il y en a beaucoup des catégories ?
Tu peux utiliser des masques binaires

moi je ferai une table document avec un clé primaire id_doc, une table catégorie avec une clé primaire id_cat et une table de liaison doc_cat avec 2 colonnes (id_doc, id_cat) et comme clé primaire (id_doc, id_cat).
surtout pas utiliser la méthode avec les like, parce que tu te trouveras avec des requêtes non optimisées et lourdes pour ton serveur (et donc pour ton temps de réponse).
 
A+
Dropsy

dropsy >> C noté. Merci bcp !
 
Bebert >> - de 100 catégories et - de 1000 docs donc ça ne fait pas trop. Les masques binaires OK, mais c quoi ?? C comme le sys de permissions de fichiers ? Où puis-je me documenter sur ça ? Est-ce mieux que la solution de dropsy ?

100 catégories  
Ca ira pas  
 
C'est tout simplement le fait d'utiliser les bits d'un entier.
1er  bit positionné -> 1ère catégorie
2ème bit positionné -> 2ème catégorie
...
 
Pour faire une recherche, tu peux utiliser un masque.
SELECT * FROM table WHERE categorie & 5
pour ceux qui ont la catégorie qui correspond au bit 2 et 0
 
Si tu n'avais qu'une dizaine ou une vingtaine de catégories, c'est bon. Mais un entier sur 100 bits, ca fait beaucoup

mrBebert > je connaissais pas cette technique  
j'en vois pas trop l'intéret. Tu l'utilises dans quels cas?

C'est pratique pour regouper plusieurs propriétés "simples" (oui/non généralement) dans peu d'espace.
 
Par exemple, pour des droits dans une table de personnes, c'est idéal. Plutot que de définir plusieurs colonnes correspondant chacune à un droit et ne contenant que 2 valeurs (oui ou non), autant tout regrouper dans un seul champ.
Ca occupe peu de place et c'est facile à manipuler  
 
Ca aurait été adapté à ton cas si tu avais eu moins de catégories.

 
C'est bien ce que je me disais : c comme la gestion des droits RWX. Même si ça ne va pas pour mon cas, j'ai appris qq chose au moins !

 
J'ai été obligé de mettre 2 index dans ma table liaison :
PRIMARY KEY (doc_id, cat_id);
INDEX (cat_id);
 
Sinon ma requête parcourait toute la table documents. Comprends pas pkoi vu que les index sont sur la tabel liaison ????
Si qq'un a la clé du mystère.

2 clés primaires tu veux dire ? c normal, puisque la clé doit être unique. (j'ai du mal à cerner ton problème)
 
sinon, ceci devrait être plus optimisé

Index sur documents :

 
Index sur liaison :

 
Explain de la requête

 
Si on enlève l'index cat (le 2e, pas le primary) de la table liaison eh bien la table documents est parcourue en entier :

Pourtant ça ne devrait pas car d'un côté du AND j'utilise la première partie de l'index (doc) et de l'autre côté du AND la seconde partie (cat).

Ca y'est j'ai résolu le pb avec cette requête :

J'ai bien entendu inverser le PRIMARY KEY en mettant cat,doc au lieu de doc,cat... Now ça fonctionne bien. Avant c'était moins optimisé car ça faisait la jointure entre les deux tables avant de sélectionner la catégorie. Maintenant ça sélectionne la catégorie et ça fait la jointure après comme ça on a moins de données à joidre.

c'est ce que j'ai dit (enfin, je l'ai pas expliqué...)
 

Sans me dire d'intervertir la PRIMARY KEY et de suppr le 2e index ! Mais effectivement c'est en lisant ton message que j'ai eu l'idée. Donc MERCI !

oups j'avais pas vu    
je ne savais pas que cela avait bcp d'importance l'ordre des primary key.
donc c'est moi qui te remercie, je ferai plus attention la prochaine fois