Factorisation en base de donnée

Factorisation

La factorisation, qu'est ce que c'est ?

On parle factorisation de code quand on essaye d'extraire les points communs entre plusieurs problèmes, afin de ne les traiter qu'une seule fois.

Basiquement, l'utilisation d'une fonction (ou d'une procédure) appelée plusieurs fois dans un programme est la première forme de factorisation.
L'héritage en programmation orientée objet est un puissant outil de factorisation : le même code étant propagé à tout une famille d'objets présentant des caractéristiques communes.
La notion de service dans les architectures orientées service est une autre forme de factorisation.
etc.

Je pourrais ainsi faire une longue liste, mais ceci n'aurait pas d'intérêt et il y aura toujours un emmerdeur puriste pour débattre, vendre sa vision de la chose ou insister pour rajouter ou mettre en avant sa méthode favorite. L'objectif ici est simplement de justifier la suite de cet article.

L'idée ici est de montrer comment, grâce à ActiveRecord, on va pouvoir factoriser une partie du travail sur la base de donnée.

Factoriser le code, pourquoi faire ?

Pour éviter de refaire le même travail plusieurs fois.
Pour simplifier la maintenance d'une application
Pour généraliser une best-practice dans un framework
etc.

En l'occurence, ce qui m'intéresse ici c'est de factoriser la mise en place de certains champs quasi-obligatoires dans ma base de donnée.

Factoriser ma base de donnée

Points communs

Quels sont les points communs entre toutes les données nécessaires pour coder mon blog ?

• Je souhaite tout d'abord qu'elles soient toutes identifiées de façon unique
• Je veux que cette identification se fasse par un entier (principalement pour des questions de performance)
• Parfois je pourrais aussi être amené à utiliser d'autre identifiant, notamment les GUID
• J'aimerai stocker la date de création de la plupart des données
• Il me semble sensé de noter également la date de dernière modification
• Idéalement, il faudrait également connaitre l'identité de l'utilisateur ayant créé cette donnée
• Et tant qu'à fait, si on pouvait également noter l'identité de l'utilisateur ayant fait la dernière modification

Mes champs communs

Grâce à la liste ci dessus, j'ai la liste des champs que veux dans chacune des données de ma base :

• ID - un identifiant, soit entier, soit GUID
• DateCreation - la date de création de mon entrée en base
• DateModification - la date de dernière modification
• IdCreator - l'identité du créateur
• IdUpdator - l'identité du dernier utilisateur ayant modifié cette donnée

Quelques explications

Pourquoi ne pas stocker un historique global des modification ?
Ca serait très pratique en effet
Disons que d'expérience c'est beaucoup plus compliqué à mettre en place. On verra pour la v2.

Pourquoi utiliser des GUID pour identifier des données ? Il peut y avoir deux raisons :

• Lorsque plusieurs bases de données peuvent créer des entrées dans une même table. La gestion d'un identifiant entier auto-incrémenté pose alors des problèmes de synchronisation.
• Lorsqu'on veut pouvoir exposer un identifiant de façon sécurisée. Il est plus difficile pour un hacker de deviner un GUID que d'essayer différents entiers pour récupérer les informations d'un autre utilisateur ou d'un élément auquel il n'a pas accès. Dans une URL typiquement.

Pourquoi 'DateCreation' et pas 'CreateDate' ?
Parce que j'essaye de toujours mettre le type de la donnée en premier.
Ma règle implicite de nommage c'est 'quoi' en premier. D'où les "IdSchtroumpf" et pas "SchtroumpfId".
C'est une convention de nommage personnelle qui m'apporte beaucoup en terme de lisibilité.