J'ai compris merci beaucoup.

En fait, dès le moment où tu as une relation de type n,m (un élément de la table A peut être associé à n éléments de la table B, et un élément de la table B peut être associée à m éléments de la table A) alors une table de liaison s'impose. Celle-ci est composée des identifiant des deux tables qui forment ensemble la clé primaire de la table de liaison.

Ainsi, tu as sur la table d'association la clé : PRIMARY KEY (id_tag, id_image)
et il n'est donc pas nécessaire d'y ajouter d'index.

Merci, j'avais deja rencontré ce type de solution, mais jamais essayé.
id_tag sert d'index pour les deux tables ou je crée un ID pour la seconde table ?

ID, id_tag, libellé

A priori je dirais que le plus propre serait de faire

• - une table pour les tags du genre :
  • - id_tag
    - libelle
  - une table d'association entre un tag et une image :
  • - id_tag
    - id_image

De cette façon tu pourras simplement avoir le même tag associé à plusieurs images, plusieurs tags pour une même image et compter le nombre de fois qu'est utilisé un tag (pratique pour le nuage de tags).[/list]

Bonjour
j'ai besoin d'un conseil sur la conception d'un systeme de photos taggées.

est-ce qu'il faut mieux mettre tous les taggs dans une table à part ( ID, tagg) ou est-ce qu'il faut mettre les taggs directement dans un champs de la table photos ?

Si les taggs sont dans une table à part je vais avoir avec un champs de la table photo tagg, du style ( ID2, ID8,ID44,ID66...) ou (tagg2, tagg8, tagg44, tagg66), ça me semble difficile à gérer surtout pour les mises à jour. Mais c'est sans doute plus pratique pour afficher et trier tous les taggs.

Si je met les taggs "en dur", directement dans un champs de la table photo, je vais devoir effectuer de nombreuse opération sur la table photo, il me semble, pour recupperer les tags les plus utilisés -par exemple- ou pour es classer...bref je sais pas sur quel pieds danser. J'espère avoir été clair

une idée ?
merci