serveur iPASS et SQL
Pour comprendre le concept qui a permis la démonstration précédente, rien ne vaut un petit détour côté technique. Et plus précisement côté SQL...
Le serveur iPASS manipule deux tables SQL particulières : ps_ipass et ps_ipass_auth. La première table contient les informations sur les utilisateurs concernés par le système iPASS. La seconde table gère les accès à cette première table (à ce stade, c'est sans importance).
La clé de compréhension du serveur iPASS tient dans le principe suivant : les deux tables SQL peuvent être rénommées et/ou déplacées vers une autre base de données ou vers un autre serveur SQL. Indépendamment des autres tables SQL nécessaires au fonctionnement de phpStudio. Pourquoi dès lors ne pas envisager de déplacer ces tables pour les noyer parmi des tables d'une autre application (dans l'exemple précédent : IPB 1.3) ?Qu'est ce qui empêche de déplacer ces tables sur une autre base de donnée, sur un autre serveur et éventuellement même un autre SGBD ? Et si on s'arrangeait pour éviter des tables redondantes ? Car après tout, le contenu de la table ps_ipass (nom, email, mot de passe...) est très certainement déjà présent ailleurs...
C'est ici qu'intervient le driver iPASS. Son objectif est de faire la correspondance entre la structure de phpStudio et celle d'une tierce application. Lors de l'installation de phpStudio, ce driver iPASS permet de savoir quelle base de données utiliser, comment l'atteindre, quelles tables et/ou quels champs SQL sont à créer ou modifier, quelles tables et quels champs SQL correspondent à quoi et, pour compléter la correspondance, quel format utiliser pour les mots de passe.
Finalement, quand on y repense, ce n'est pas aussi compliqué que ça aurait pu en donner l'impression. Non ?
Puisque ce billet aborde l'aspect SQL, il est intéressant de noter la problèmatique abordée met en évidence l'intérêt d'un couche d'abstraction de base de données. La présence de cette couche d'abstraction est "imposée" par des contraintes externes à phpStudio. Pour bien faire, l'application doit en effet être capable d'exploiter la base de données d'une tierce application, indépendamment de SGDB utilisé par phpStudio et quelle que soit la nature de cette base de données : mySQL, SQLite, postGreSQL, Oracle, Firebird...
Accessoirement ce concept d'iPASS permet aussi de s'intéresser aux notions de Design Patterns et de singleton. Mais ça, c'est une autre histoire...