Forum: Rails France definition table pour des tags

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
D893e113b51a8f200d2abb3ed9e54143?d=identicon&s=25 Gaspard Bucher (gazoduc)
on 2008-11-20 17:31
(Received via mailing list)
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

2. 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
1. 200'000 entrées, 4'000 tags = 9.8M
2. 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 ?
7add1eff4adafe6012b2e719dbf2bdc7?d=identicon&s=25 Arthur Pétry (Guest)
on 2008-11-20 17:39
(Received via mailing list)
Le 20 nov. 08 à 17:30, Gaspard Bucher a écrit :

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

Arthur
A99870c1391c39da2089649745965bda?d=identicon&s=25 Jean-François Trân (Guest)
on 2008-11-20 17:45
(Received via mailing list)
Le 20 novembre 2008 17:38, Arthur a écrit :

>> 2. 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_
98d4d4be867fc17d3120f683513d3819?d=identicon&s=25 Guillaume Betous (Guest)
on 2008-11-20 20:46
(Received via mailing list)
> 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/
D893e113b51a8f200d2abb3ed9e54143?d=identicon&s=25 Gaspard Bucher (gazoduc)
on 2008-11-20 22:45
(Received via mailing list)
> 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
98d4d4be867fc17d3120f683513d3819?d=identicon&s=25 Guillaume Betous (Guest)
on 2008-11-21 07:33
(Received via mailing list)
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/
D893e113b51a8f200d2abb3ed9e54143?d=identicon&s=25 Gaspard Bucher (gazoduc)
on 2008-11-21 08:28
(Received via mailing list)
2008/11/21 Guillaume Betous <guillaume.betous@gmail.com>:
>
>
> 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
D893e113b51a8f200d2abb3ed9e54143?d=identicon&s=25 Gaspard Bucher (gazoduc)
on 2008-11-21 09:23
(Received via mailing list)
2008/11/21 Gaspard Bucher <gaspard@teti.ch>:
> 2008/11/21 Guillaume Betous <guillaume.betous@gmail.com>:
>>
>>
>>> 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)
This topic is locked and can not be replied to.