Retour : Page Principale > sommaire applications botaniques > CEL

Mémo sur la refactorisation de la gestion des tags du cel


Situation actuelle

Les tags du cel sont gérés par un système dit "d'arbre intervallaire" (voir http://sqlpro.developpez.com/cours/arborescence/ ).
Avantages :
  • lecture de l'arbre en entier et de ses sous arbres très rapides.
  • pas de récursivité dans la représentation de l'arbre.

Inconvénients :
  • insertion et modification très coûteuses
  • nécessite des transactions pour fonctionner (plusieurs opérations ne doivent fonctionner qu'ensemble)
  • système fragile et facilement cassable
  • impossible de fusionner deux arbres de mots clés (lors de fusions de compte CEL par exemple)

Besoins

Le nouveau système doit avoir les avantages suivants :
  • insertion et modification des tags facile
  • hiérarchie de l'arbre facilement reconstructible en cas de problème
  • possibilité de fusionner deux arbres sans trop de problèmes.
  • interrogation des obs ou images qui correspondent à un tag très facilement.
  • liaisons des obs ou des images aux tags facilement

Questions ?
  • Garde t'on le même set de fonctionnalités (en particulier le déplacement d'un sous arbre) ?
  • Garde t'on le concept d'arbre ?
  • Garde t'on la possibilité d'avoir des tags qui ont le même nom à plusieurs endroits différents ?
  • Identifiant du tag doit il devenir un slug du tag (ou le tag lui même) ?
  • Manière de lier les mots clés aux obs (garder le système actuel table clé à clé ou bien ajouter un champ naturel dans la table de liaisons ?)
  • Des tags par utilisateur et des tags partagés ?

Propositions

Un article détaille plusieurs solutions (dont celle employée actuellement) : http://fr.slideshare.net/billkarwin/models-for-hierarchical-data
Deux solutions retiennent l'attention :
  • Path énumeration (hierarchie où l'on stocke les chemins à base de "/")
  • Closure table (table à relation n-n qui stocke les liens entre un noeud et tous ses descendants).

Path enumeration
Avantages :
  • Simplicité de requêtes sur les descendants et ancetres
  • Déplacer un bout de l'arbre revient à renommer un chemin
  • Possibilité d'interroger par hierarchie (directe ou indirecte) de tags

Inconvénients :
  • Requete sur les descendants à base de LIKE % (performance ?)
  • Pas d'intégrité référentielle
  • Redondance de l'information
  • Nécessité de faire des triggers pour la mise à jours chemins
  • Parfois ça chie dans la colle, un dossier se retrouve à plusieurs reprises dans le path (ex: /projets cooperatifs/floraisonods/projets cooperatifs/laureat/projets cooperatifs/) et l'interface des mots clés bug (liste vide) il faut alors vérifier et corriger les tags bugués un par un en base

Closure table
Avantages :
  • Organisation des tags distincte des tags eux même (facilité à changer de système)
  • Requetes déjà fournies dans l'articles
  • Possibilité de retrouver facilement toutes les relations entre tous les noeuds
  • Intégrité référentielle (performance +)

Inconvénients :
  • 2 tables
  • nécessité de calculer une colonne "profondeur" pour obtenir facilement les descendants directs

Solution retenu

La solution à base de path enumeration a été retenue.
Elle a été mise en place dans la version 2.0 « Élagueuse » en février 2014.