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.
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
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.