Principes Généraux

But

L'idée sous jacente ici est de concevoir une architecture simple et générique que l'on pourrait réutiliser pour concevoir facilement de petites applications :

• un petit tracker
• un todo list personnel
• etc ...

Ce voulant générique elle ne pourrait pas répondre à toutes les spécificités d'un projet.

Introduction

Stocker de l'information dans une base de données est un besoin commun, seul la manière de stockage différé entre les projets. Sur Internet, les CMS proposent des solutions permettant de publier des informations divers. Si pour divers raison o ne souhaite pas utiliser de CMS, la question du stockage et de l'organisation des données doit être réfléchie.

Pour cela, voici un système de stockage particulier et générique basé sur une notion très à la mode : le tag.

Détails

Le contenu à stocker peut être vu comme des informations auxquelles on attache des caractéristiques ! Le principe de base est de considérer les informations comme un ensemble d'items et les caractéristiques comme un ensemble de tags.

On a donc 2 grandes notions :

• Des items
• Des tags

Pour être générique on doit pouvoir stocker différents types d'informations et y attacher plusieurs types de caractéristiques. On a donc 2 sous-notions :

• Des types d'items
• Des types de tags

On peut même associer ces deux notions en considérant qu'à chaque type d'items correspond plusieurs types de tag.

Modèle conceptuel

Si on modélise le principe énoncé auparavant on obtient un schéma théorique en 3FN suivant :

        

       +------+ 1           +-----------+
       | ITEM |-------------| TYPE_ITEM |
       +------+           n +-----------+
         n|                       | n
          |n                    1 |
       +-----+              +----------+
       | TAG |--------------| TYPE_TAG |
       +-----+              +----------+

        

Modèle optimisé

Si on applique au modèle conceptuel le principe que "tout est tag" on peut considérer que les types d'items et les types de tags sont des tags particuliers, et même qu'un item n'est rien d'autre qu'un tag.

On obtient donc un schéma optimisé :

        

                 n +-----+  1
               +----| TAG |-------------+
               |    +-----+\            | Type 
               |       |    \ n           |
               |       |     +----------+
               |     1 |
               | 1 +--------+
               +---| TAGGED |
                   +--------+


        
    

Exemple concret

Pour mieux illustrer le modèle théorique prenons par exemple le stockage d'un "bugtraker"

Un seul type d'item : des bugs Les bugs possèdent plusieurs types de tags : Version, Etat, Rapporteur

On obtient donc une liste à plat de données (les sous niveau correspondent à une vue développée)

        

    * tag_type
    * version
          o tag_type 
    * rapporteur
          o tag_type 
    * état
          o tag_type 
    * item_type
    * bug
          o item_type
          o version
                + tag_type 
          o rapporteur
                + tag_type 
          o état
                + tag_type 
    * v1
          o version
                + tag_type 
    * v2
          o version
                + tag_type 
    * résolu
          o état
                + tag_type 
    * nouveau
          o état
                + tag_type 
    * affecté
          o état
                + tag_type 
    * titi
          o rapporteur
                + tag_type 
    * toto
          o rapporteur
                + tag_type 
    * Bug #1
          o bug
          o v1
                + version
                      # tag_type 
          o résolu
                + état
                      # tag_type 
          o titi
                + rapporteur
                      # tag_type 
    * Bug #2
          o bug
          o v2
                + version
                      # tag_type 
          o nouveau
                + état
                      # tag_type 
          o toto
                + rapporteur
                      # tag_type 
    * Bug #3
          o bug
          o v1
                + version
                      # tag_type 
          o affecté
                + état
                      # tag_type 
          o toto
                + rapporteur
                      # tag_type 

        
    

Avantages

Il y a principalement deux avantages :

• On peut stocker n'importe quoi à n'importe quel moment, il est inutile de définir de nouvelle colonne ou de nouvelle table
• La recherche d'information se fait sans avoir besoin d'une sur-indexation. Toutes les données sont au même niveau. Une simple requête SQL permet de faire de recherche sur tous les critères

Inconvénients

• Les données sont inexploitable sans passaient par un programme
• Une seule table contient quasiment toutes l'information
• C'est le raisonnement inverse d'un schéma de base de données traditionnelle

Typage

Jusqu'à présent on ne s'est pas soucié du type de chaque caractéristiques. Or on peut en avoir plusieurs : chaine de caractère, nombre, date, etc...

Ce type de structure impose de prévoir une conversion en chaine de caractères avec éventuellement un stockage annexe dans le type original.

Concrètement pour chaque TAG on aurait plusieurs champs correspondant à chaque type de données (éventuellement vide si la conversion n'a pas de sens).

        

  +--------------------+
  |  TAG               |
  +--------------------+
  | label              |
  | label_en_entier    |
  | label_en_date      |
  | label_en_flotant   |
  | ...                |
  +--------------------+

        

Exceptions

Ce type de structure convient bien à des caractéristiques courtes et simple. Si un item comporte un texte assez important, une image, un document. Il est nécessaire de stocker ces informations de manière traditionnelle.