Definition table pour des tags


#1

Salut à tous !

Je commence l’implémentation de tags pour zena et je voudrais
connaître les raisons de l’utilisation d’une table séparée pour les
tags:

  1. object id ----> [object_id, tag_id] -----> [tag id, name]

au lieu de

  1. object id ----> [object_id, tag name]

Si la raison de ce changement est lié à la taille de la base de
données, c’est négligeable:

  1. 200’000 entrées, 20’000 tags différents = 14M
  2. 200’000 entrées, 4’000 tags = 9.8M
  3. 200’000 entrées [object id,tag name] = 26M

10M, c’est la taille de trois images…

Y a-t-il vraiment une autre différence en terme de performance entre
ces deux solutions ?


#2

Le 20 nov. 08 à 17:30, Gaspard B. a écrit :

  1. object id ----> [object_id, tag name]
    Tu fais comment pour renommer un tag dans le cas 2 par exemple ?

Arthur


#3

Le 20 novembre 2008 17:38, Arthur a écrit :

  1. object id ----> [object_id, tag name]

Tu fais comment pour renommer un tag dans le cas 2 par exemple ?

Ben t’as juste 10Mo de données à te palucher, pourquoi ?

-- Jean-François.


Rails Party à Paris dimanche 30 novembre !

http://twitter.com/underflow_


#4

Je commence l’implémentation de tags pour zena et je voudrais
connaître les raisons de l’utilisation d’une table séparée pour les
tags:

Comme te l’ont fait remarquer Arthur et Jean-François, c’est pour éviter
la
redite.
Un tag => une entrée dans la table tags, repérée par un tag_id
Le jour où tu veux ajouter un attribut dans ton tag (d’ici 2 ou 3
versions
t’auras bien une idée géniale qui a besoin de taguer les tags (-; ), ça
se
fera bcp plus facilement.

C’est en soit le principe de toute BdD : ce choix que tu fais (mettre
directement le tag ou créer une table tags) serait à faire à chaque
fois, en
considérant la facilité de mise à jour (avantage solution 1), le gain de
place (avantage solution 1) mais aussi la rapidité d’accés à tes données
(avantage solution 2).

gUI


Pour la santé de votre ordinateur, préférez les logiciels libres.
Lire son mail : http://www.mozilla-europe.org/fr/products/thunderbird/
Browser le web : http://www.mozilla-europe.org/fr/products/firefox/
Suite bureautique : http://fr.openoffice.org/


#5

Et je ne vois pas bien qui déciderait de changer un tag.

Ca fait un argument de moins pour la solution (1).

Mon problème est vraiment technique. Pourquoi tout le monde choisit
l’option avec deux tables alors que personne n’a implémenté le
renommage de tag ?

Faut pas dire “tout le monde”. Mais c’est vrai qu’il peut y avoir une
dérive
actuelle vers le “tout table”. AR, en simplifiant fortement la gestion
de
ces tables participe (c’est pas du tout un reproche bien sur), participe
Ã
cette dérive.
En réfléchissant à ton modelle, tu tombes sur un
“has_and_belongs_to_many”
(puisque si j’ai bien compris un objet peut avoir plusieurs tags et un
meme
tag peut servir à plusieurs objets), et donc, l’implémentation qui en
découle est une table intermédiaire.

Il me semble que le tag en est une.

En effet ça peut être le cas : pas bcp d’informations ne sont attachées
à un
tag, donc pourquoi pas. Mais comme je disais dans mon post précédent,
c’est
une question à se poser à chaque fois, comme quoi il n’a jamais été
question
que la réponse soit automatique.

gUI


Pour la santé de votre ordinateur, préférez les logiciels libres.
Lire son mail : http://www.mozilla-europe.org/fr/products/thunderbird/
Browser le web : http://www.mozilla-europe.org/fr/products/firefox/
Suite bureautique : http://fr.openoffice.org/


#6

2008/11/21 Guillaume B. removed_email_address@domain.invalid:

En effet ça peut être le cas : pas bcp d’informations ne sont attachées à un
tag, donc pourquoi pas. Mais comme je disais dans mon post précédent, c’est
une question à se poser à chaque fois, comme quoi il n’a jamais été question
que la réponse soit automatique.

Je suis d’accord. C’est la raison pour laquelle il y a une table
“documents_content” en plus de “versions” et “nodes”. Ça permet
d’éviter la copie d’un document (d’une image) si on change ou si on
traduit sa description. Idem pour les contacts (contact_contents),
etc. Je ne suis pas du tout opposé à la séparation des tables ! Je
suis juste surpris par l’implémentation des tags en plusieurs tables
puisque ça complique l’implémentation, ça ralenti l’exécution (plus de
requêtes) et ça ne semble rien apporter de plus, d’où ma question.

Et puis c’est vrai “tout le monde” est un vilain canard. C’est pas
approprié comme expression.

Gaspard


#7

2008/11/21 Gaspard B. removed_email_address@domain.invalid:

2008/11/21 Guillaume B. removed_email_address@domain.invalid:

Et je ne vois pas bien qui déciderait de changer un tag.

Ca fait un argument de moins pour la solution (1).

Epilogue:
Si vraiment il faut renommer un tag (la table contient 200’000 entrées) :

update tags set tag=‘bob’ where tag=‘fe5dbbcea5ce7e2988b8c69bcfdfde8904aabc1f’;
Query OK, 12225 rows affected (3.60 sec)


#8

fera bcp plus facilement.

C’est en soit le principe de toute BdD : ce choix que tu fais (mettre
directement le tag ou créer une table tags) serait à faire à chaque fois, en
considérant la facilité de mise à jour (avantage solution 1), le gain de
place (avantage solution 1) mais aussi la rapidité d’accés à tes données
(avantage solution 2).

gUI

Je comprends bien que la version (1) est plus “élégante”. En ce qui
concerne le changement de nom pour un tag, ça n’arrivera jamais ou
alors il faudrait avoir une entrée “site_id” en plus dans la table
tags. Et je ne vois pas bien qui déciderait de changer un tag. Si ça a
un statut spécial (genre définit par un document qualité), alors ce
n’est pas un tag mais un nœud dans le système et le fait de “tagger”
fait un lien entre ce nœud et l’objet source au travers d’une
“relation” (par exemple on peut “tagger” un nœud comme non-conforme en
le liant à un nœud de class “exception” à travers une relation
“quality_marker”). Dans ce cas le tag “exception” est un nœud comme un
autre qui peut être lié à d’autres, etc. Ceci marche très bien. (image
illustrant ce fonctionnement: http://zenadmin.org/411).

Les tags dont je parle ne servent qu’à marquer du contenu facilement
sans avoir la surcharge liée à la création de nœuds pour enregistrer
“design” ou “famille” ou je ne sais pas quoi. Ils doivent donc être le
plus “légers” possibles (pas de droits à gérer pour ajouter un tag ou
le renommer, etc).

Mon problème est vraiment technique. Pourquoi tout le monde choisit
l’option avec deux tables alors que personne n’a implémenté le
renommage de tag ? Mon idée est que les livres sur le design de bases
de données disent “contenu dupliqué = attention: mauvais design” mais
je pense qu’il y a des situations où l’exception à cette règle saine
fait sens. Il me semble que le tag en est une.

Si vous pensez que la table simple (2) est un hérésie en tenant compte
du fait que zena a tout un système de “relations” pour les
tags-qui-sont-des-nœuds, je serais heureux d’entendre vos arguments.

Gaspard