Système de tags pour catégoriser des textes [Résolu]

[yazerty]

Bonjour,

Je suis en train de voir quel système je pourrais mettre en place afin de "catégoriser" les textes de mon site de rêves, la Boîte à rêves.

Je penche pour un système de tags, qui permet une plus grande souplesse qu'un système de catégories prédéfinies et plus rigide : on ne pourrait attribuer qu'une catégorie pour chaque rêve, mieux vaut donner la possibilité d'attribuer plusieurs critères pour un même rêve et donc utiliser un système de tags un peu modifié avec une restriction des tags possibles. Par "restriction des tags possibles" je veux dire que je veux proposer une liste de tags possibles (liste cependant) assez large pour satisfaire les besoins.

N'étant pas un pro en programmation je recherche donc une base pour élaborer un petit système de tags.

En connaissez-vous des bon, bien codés et facilement modifiable (donc simples) ?

[hisy]

Gutten tag ...

Excuse mon ignorance mais qu'est-ce que tu entends par tag ?

[yazerty]

http://www.neokraft.net/ (blog du système de blogs DotClear) par exemple les utilise depuis peu, mais on retrouve les tags dans tous les projets "récents" : blogmarks, flickr, ...

[macbook]

Il doit s'agir d'un plugin. Demande à Olivier Meunier.

[yazerty]

Oui oui c'est sans doute un plugin de DC 2, mais il n'est pas encore disponible (DC 2 n'est pas encore sorti et il s'agit là d'un blog de "test")...

[macbook]

Dotclear (même si j'aime pas) est hyper bien foutu, et il serait étonnant que tu ne parviennes pas à bidouiller le code pour parvenir assez rapidement à tes fins.

[yazerty]

Moui, mais le système de tags de DotClear n'est pas encore disponible !! Et je demandais s'il existe un petit script générique uniquement pour créer un petit système de tags ?

[Mr N.]

Code :

1
2
3
4
 
DREAMS(id, title, ...)
TAGS(id, label)
TAGS_DREAMS(dream_id, tag_id)

Code :

1
2
<input type="text" name="tag[]" />
<input type="text" name="tag[]" />

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
$tags = get_tags_from_request();
//link tag with dream
foreach($tags as $tag)
{
   $sql = "SELECT id FROM tags WHERE label = '".quote_smart($tag)."'";
   $req = mysql_query($sql);
   if (mysql_numrows($req) > 0)
   {
      $tag_id = mysql_result($req, 0, 0);
   }
   else 
   {  //create new tag
      $sql = "INSERT INTO tags (label) VALUES ('".quote_smart($tag)."')";
      $req = mysql_query($sql);
      $tag_id = mysql_insert_id();
   }
 
   //Link tag with dream
   $sql = "INSERT INTO tags_dreams (dream_id, tag_id) VALUES ('". $dream_id ."', '". $tag_id ."')";
   $req = mysql_query($req);
}

Code :

1
2
3
4
5
6
function search_dreams_by_tag($tag)
{
   $sql = "SELECT d.id FROM dreams d, tags t, tags_dreams td WHERE t.label = '".$tag."' t.id = td.tag_id and td.dream_id = d.id";
   $req = mysql_query($sql);
   ...
}

etc. etc.

[yazerty]

Merci pour ta réponse Mr N.

Par contre comment prendrais-tu en compte le fait qu'il puisse y avoir plusieurs tags sur un même rêve ? Il y aurait plusieurs "lignes" correspondant au rêve dans la table TAGS_DREAMS ? Question performances c'est le mieux (je ne m'y connais pas, c'est une simple question de curiosité et d'intérêt en tant que webmaster) :- ?

[Mr N.]

C'est tout l'intéret d'avoir une table tags_dreams : permettre à un reve d'avoir plusieurs tags. Si un reve n'avait qu'un tag, il aurait fallu rajouter une colonne 'tag' dans la table dreams.

Et ca n'a rien à voir avec les performance, c'est une question de principe: les relations multivaluées se mettent dans des tables à part.

[Yogui]

Envoyé par Mr N.

Et ca n'a rien à voir avec les performance, c'est une question de principe: les relations multivaluées se mettent dans des tables à part.

Complètement d'accord. En analyse, cela se traduit par les cardinalités "1,1 / 0,N" ou "1,1 / 1,N".

[Mr N.]

Envoyé par Kirkis

Complètement d'accord. En analyse, cela se traduit par les cardinalités "1,1 / 0,N" ou "1,1 / 1,N".

Là je suis pas tout à fait d'accord
Si j'ai la relation suivante :

Code :

1
2
3
+-------+ 1,1              0,n +-------+
|   A   |----------------------|   B   |
+-------+                      +-------+

Alors ma bd sera comme ceci :

Code :

1
2
3
 
A(id, ...)
B(id, ..., a_id)

Pour moi une table à part ce fait principalement quand on a des relations n-n

[Yogui]

Code :

1
2
3
+-------+ 0,n              0,n +-------+
|   A   |----------------------|   B   |
+-------+                      +-------+

Cela donne lieu à une table de jointure.

Code :

1
2
3
+-------+ 1,1              0,n +-------+
|   A   |----------------------|   B   |
+-------+                      +-------+

Cela donne lieu à une clef étrangère de A dans B, comme tu l'as dit.

Code :

1
2
3
+-------+ 1,1              1,1 +-------+
|   A   |----------------------|   B   |
+-------+                      +-------+

C'est une erreur de modélisation : les deux tables devraient être fusionées.


Me trompé-je ?

[Mr N.]

Ehhhh y'a copyright sur les dessins ascii

Je ne suis pas d'accord pour la dernière. Ce n'est pas une erreur de modélisation.
Une voiture possède un moteur. Un moteur n'appartient qu'à une seule voiture.

Code :

1
2
3
 
voiture(immatriculation, couleur, ..., moteur_numero_serie)
moteur(numero_serie, type_carburant, ...)

ou

Code :

1
2
3
 
voiture(immatriculation, couleur, ...)
moteur(numero_serie, type_carburant, ..., voiture_immatriculation)

Ne commencerait-on pas à être hors-sujet là ?

[Yogui]

Conceptuellement, ton moteur n'appartient pas à la voiture. C'est bien une entité à part qui peut exister de son côté, sans voiture.
Tu n'as pas une relation 1,1 / 1,1 pour l'histoire moteur / voiture car chaque moteur a des caractéristiques communes à tous les moteurs de sa série. Ne confonds pas "entité conceptuelle" et "tuple"...

Dans la mesure où l'auteur du sujet a posé une question de modélisation, je ne crois pas que nous soyions hors sujet ^^


Désolé pour le copyright, c'était pour que nous parlions de la même chose de la même manière

[Mr N.]

Tu n'as pas une relation 1,1 / 1,1 pour l'histoire moteur / voiture car chaque moteur a des caractéristiques communes à tous les moteurs de sa série.

J'ai mal pris mon exemple en donnant un mauvais identifiant au moteur.

Bon je prend un autre exemple.

Un paiement règle une vente.

Code :

1
2
3
4
5
6
+--------------+ 1          règle   1 +-----------+
|   Paiement   |----------------------|   Vente   |
+--------------+                      +-----------+
| montant      |                      + date      +
|              |                      + heure     +
+--------------+                      +-----------+

Dans mon modèle, à tout instant t, une Vente est règlée par un Paiement et un Paiement règle une Vente.
Je ne vais pas fusionner mes deux objets car j'aimerais plus tard avoir PaiementChèque, PaiementCarteBancaire et donc avoir des informations supplémentaires propres au paiement en question et non pas à la vente.
Mais encore une fois, tout dépend du contexte, mais juste pour dire qu'une relation 1-1 est possible est correcte.

T'inquiète pour le copright, c'est sous license LGPL

[yazerty]

Envoyé par Mr N.

C'est tout l'intéret d'avoir une table tags_dreams : permettre à un reve d'avoir plusieurs tags. Si un reve n'avait qu'un tag, il aurait fallu rajouter une colonne 'tag' dans la table dreams.

Et ca n'a rien à voir avec les performance, c'est une question de principe: les relations multivaluées se mettent dans des tables à part.

Ok. Non mais j'imaginais que dans certains cas on pouvait avoir un table avec par exemple :
id_reve = 68; id_tags = 1,5,9

Les 1,5,9 étant dans le même champ et devant être traités pour séparer les valeurs des différents tags, pour aller ensuite chercher leurs labels dans une autre table.

Mais c'est peu-être un peu plus tordu ;- ?

Sinon à propos de ton code j'ai quelques questions :

1°) A quoi servent les [ ] dans le name="tag[ ]" ?
2°) A quoi servent les lignes suivantes :

Code :

1
2
3
$tags = get_tags_from_request();
//link tag with dream
foreach($tags as $tag)

Je ne comprends pas leur fonctionnement. J'en suis aux très basiques boucles while pour les requêtes .
Où est fénifie la fonction get_tags_from_request() ? et à que veut dire le "$tags as $tag :- ?

ps : concernant vos discussions techniques, comme je n'y comprends rien du tout je ne peux qu'espérer pouvoir être de l'avis de l'un ou de l'autre un jour ...

[Mr N.]

Envoyé par yazerty

Ok. Non mais j'imaginais que dans certains cas on pouvait avoir un table avec par exemple :
id_reve = 68; id_tags = 1,5,9

Les 1,5,9 étant dans le même champ et devant être traités pour séparer les valeurs des différents tags, pour aller ensuite chercher leurs labels dans une autre table.

Mais c'est peu-être un peu plus tordu ;- ?

Je t'invite à jeter loin, très loin, cette idée. C'est tordu, non maintenable, moche, lent, ... si je puis me permettre

1°) A quoi servent les [ ] dans le name="tag[ ]" ?

A recevoir, du coté du serveur, les tags sous forme de tableau. Ex :
$_REQUEST['tag'][0] = 'voiture';
$_REQUEST['tag'][1] = 'cheval';
(Tu peux remplacer _REQUEST par _POST ou _GET suivant ton cas)

2°) A quoi servent les lignes suivantes :

Code :

A récupérer les tags qui ont été rentré par l'utilisateur. Voir la réponse à propos de [] ci-dessus.

Où est fénifie la fonction get_tags_from_request() ?

Elle est féfinie nulle part. C'est juste pour te donner une idée.

et à que veut dire le "$tags as $tag :- ?

A que ca veut dire "tu prends chaque element du tableau $tags, un par un, et tu me les mets dans la variable $tag". Plus d'info : http://fr.php.net/foreach

Note que ma proposition n'était qu'un guide vers une des multiples solutions possibles. A toi de faire selon tes envies, tes compétences et tes besoins.

[yazerty]

Oki, je jette cette idée alors ;-) !
Merci pour tes réponses. Je vais réfléchir à tout ça pour voir comment je fais la chose...

Bonne soirée 8) .