Microsql
Introduction
Les systèmes de mise en cache ont un effet remarquable sur la vitesse de production des page.
Pour éviter un grand nombre d'appels de la base de donnée MySql, le résultat des requêtes les plus courantes est stocké "en dur" (d'où le nom parfois de "hardbases").
Voici une idée fiable des scores de vitesse selon les différents moyens d'appeler un contenu :
- MySQL : 0,06 s.
- require : 0,03 s.
- fopen() + explode() : 0,123 s.
MySQL est appelé pour les grands mouvements, en quantité ou en tris. Pour les petits mouvements répétitifs, mieux vaut charger des données prêtes à l'emploi via require().
La philosophie du logiciel a toujours été la multiplicité et complémentarité des techniques.
Différentes méthodes ont été testées, en stockant les données sur des fichiers texte, en butant sur les caractères qui servent de diviseurs de ligne et de colonne, ou en utilisant la base MySql, mais ils ne peuvent jamais être bien compliqués. L'accès et l'injection des données sont les deux seules étapes de la procédure des bases en dur.
Finalement le principe de Microsql est apparu pour s'occuper du système de mise en cache des articles courants (qui sont appelés une fois, et réutilisés des dizaines de fois).
Ensuite, devant l'efficacité de ce principe novateur, il a été étendu à de très nombreuses fonctionnalités, qu'on appelle les "couches molles du système", c'est à dire celles sur lesquelles on intervient souvent, quand on rajoute des fonctionnalités.
Devant ce foisonnement d'usages, il a fallu ensuite créer toute une admin de gestion des microbases, parfaitement indépendante du logiciel.
On veut que la création d'une base de donnée puisse avoir n'importe quel format, n'importe quel nombre de colonnes, et puisse être organisés les uns avec les autres d'une manière non prédéfinie.
méthode
En microsql, on simule une base sql au moyen de données enregistrées directement au format php. Ne cherchez pas, personne sur le net ne semble supposer cette idée !
C'est la méthode la plus radicale, d'une simplicité maximale : il suffit d'enregistrer un fichier php où on a rédigé le code en php (et avec php), en une ligne qui ressemble à cela :
<?
$ret.='$'.$p.'["'.$k.'"]=array('.$ret.');'."n";
qui produit ceci :
<?
$ret["_menus_"]=array('auth_level','category');
$ret["console"]=array('5','Global');
$ret["hubs"]=array('0','Global');
$ret["nodes"]=array('7','Global');
$ret["newsletter"]=array('4','Global');
$ret["stats"]=array('4','Global');
$ret["messages"]=array('0','Global');
$ret["mails"]=array('5','Global');
et qui est appelée comme cela :
require($f);return $$plug;
Ainsi la microbase est appelée par un simple "require()", et les données sont injectées directement à la mécanique, sans avoir eu aucun traitement à faire.
L'avantage est que ces données ne sont accessibles que par le logiciel, puisqu'une page PHP appelée directement n'affiche jamais son contenu. Si ces données veulent être appelées de l'extérieur, elles le seront via XML.
L'usage a voulu que la première ligne soit dédiée à une en-tête qui nomme les colonnes, ce qui constitue un enrichissement informatif qui vaut le coup d'être administré.
Usages
- le cache des articles qui produit aussi la feuille RSS.
11 colonnes de données à propos de 150 articles pèsent 75Ko et nécessiteraient des centaines d'appels à MySql, et fédérer ces appels rimerait à freiner drastiquement la marge de manœuvre du développement.
- toute la partie "molle" du logiciel, à savoir :
-- la liste et le nom des paramètres et des restrictions ;
-- liste, noms, et types des modules internes ;
-- liste, type et paramètres des connecteurs internes ;
-- nominations et niveau d'autorisation requis pour l'accès aux menus de l'Admin ;
Dans la pratique presque toutes les additions (nouveaux modules, conecteurs, etc...) sont signalées au logiciel par les microbases.
- toutes les aides contextuelles, classés en différentes langues ;
- les paramètres locaux :
-- connecteur-utilisateur
-- modules-utilisateur
-- templates d'articles
-- bases de blocs de modules
-- les e-mails de la newsletter
-- les Defcons, les définitions d'importation de sites
- les tableaux utilisateur, qu'on insère entièrement ou partiellement dans les articles (cette méthode est destinée aux utilisateurs qui produisent des documents très structurés, où chaque article utilise par exemple la même ligne de différents tableaux, ou bien se réfère très souvent à des données ponctuelles d'un tableau très massif) ;
ainsi que :
- les paramètres utilisés pour construire le design ;
- les données relatives aux Sliders (système équivalent à PowerPoint)
- les statistiques qu'on veut purger de la base de données pour les placer sur le disque ;
- les informations sur les téléhargements de fichiers ;
- les discussions inter-sites telles que le propose le menu "tickets" de l'Admin ;
L'admin de Microsql est un peu austère, mais tout y est !
- créer une nouvelle base
- choisir le nombre de colonnes
- sauvegarder une base et la restaurer
- éditer les titres des colonnes ;
- ajouter / effacer des entrées ;
- importer une base (très pratique pour créer une traduction) ;
- importer une base depuis un autre serveur (pour le transport des design) ;
- injection de données à une table existante ;
- index à clef unique (émergence, il n'y a rien eu à faire pour cela) ;
- connecteurs :microsql permettant d'appeler le tableau ou une entrée du tableau dans un article ;
- importation / exportation depuis un tableau HTML ;
- ajouter / retirer des colonnes ;
- mettre à jour des données d'aides en ligne depuis les données système qui ont été rénovées ;
etc...
Dans chaque table une entrée nommée "_menus_" sert de référence pour le titre des colonnes.
- Chaque utilisateur d'un Hub possède un champ illimité de microbases à sa disposition ;
- Un champ "public" propose les microbases qui sont partagées ;
Par exemple dans l'Admin on peut choisir de travailler sur une base publique ou sur une base privée, quand il s'agit des Defcons (définitions d'importation de sites).
MicroXml
Les mocrobases étaient aussi très attendues pour développer les fonctionnalités inter-sites.
Le moteur de recherche de sites PHILUM pourra s'informer des tags existants et renvoyer des articles liés se situant sur d'autres sites.
MicroXml consiste à traduire une table en une référence XML standardisée.
Cela permet de transporter une table entre deux sites, mais plus encore, d'informer une application Flash avec des données qui sont faciles à gérer. Cela permet de créer des applications puissantes facilement, tel le 'Slider' qui propose d'afficher du texte et une mise en page avec la galerie photo.
Un module nommé 'Channels' consiste à utiliser les informations mises en cache des hubs pour communiquer avec d'autres sites. De cette manière on peut recevoir, comme si c'étaient des flux Rss, les articles d'un site externe, en ajoutant à cela d'autres informations telles que les tags ou le nombre de visites sur une page.
(Une autre module reçoit les flux rss de façon conventionnelle !)
Conclusion
Aujourd'hui plus rien ne peut se développer sans Microsql.
Il soulage le coeur du logiciel d'une somme très conséquente de données non formelles.
Des connecteurs et des modules sont constamment ajoutés, autant que le design par défaut et les paramètres existants ont souvent besoins d'être rénovés.
Cette innovation logicielle constitue un véritable avantage pour Philum, et surtout, elle permet à l'utilisateur de créer des bases de données personnalisées sans pour autant ouvrir une faille de sécurité qui, sans cela, aurait été béante.