Bases de données locales dans AIR

Une des fonctionnalités qui est apparue entre la release alpha et beta de AIR est l’intégration des bases de données en mode local.
Ce billet introduit cette nouveauté en plusieurs points : A quel type de SGBD a-t-on à faire? Quels utilisations peuvent en ressortir et quels changements peut-on anticiper sur les prochaines releases?

1. Présentation des SGBD Local et de SQLite

La première chose que l’on apprend lorsqu’on lit le chapitre consacré aux bases de données dans la documentation AIR est la suivante:

Adobe Integrated Runtime (AIR) includes the capability of creating and working with local SQL databases.

Bien que le concept de bases de données (BDD) locales doit être connu par une majorité des développeurs s’initiant à AIR, un petit rappel de leur propriétés n’est surement pas de trop et permettra de comprendre l’utilité de leur intégration.

La différence majeure avec les serveurs de bases de données : les bases de données locales résident dans un fichier quelque part sur le système de fichiers local et les serveurs de bases de données sur … un serveur.
Les BDD locales n’ont pas besoin d’un gestionnaire de bases de données, toutes les opérations sont effectués directement sur le fichier et on peut aussi noter l’absence de procédure d’installation et de configuration.
Ces quelques propriétés entraînent les points suivants :

+ Un coût très faible
+ La possibilité du travail offline
+ La sécurisation de données importantes

- Les accès concurrents limités
- Une capacité assez faible
- Des performances qui s’amenuisent fortement lorsque le nombre d’accès et la capacité deviennent importants
- Des problèmes d’intégrité des données (Pas de contrôle des transactions, des accès concurrents, etc…)

Il existe plusieurs implémentations de bases de données locales : Paradox, Access, dBASE, etc…
Curieusement, il est inscrit nulle part dans la doc laquelle est utilisée dans A.I.R. alors que l’annonce officiel indique le choix de SQLite.
Cette absence est justifiée par plusieurs raisons selon Paul Robertson , qui a rédigé le chapitre ‘Working with local SQL databases’ de la documentation : Il s’agit d’un détail d’implémentation que les développeurs n’ont pas besoin de savoir, les temps de développement très courts ont entrainés des prises de décisions très rapides et une rapide écriture de la documentation (on peut en effet y trouver de nombreuses fautes). Mais il ne s’agit que d’une version beta pour le moment et des changements sont sûrement à prévoir.

Quand à SQLite,

SQLite est une petite bibliothèque écrite en C qui propose un moteur de base de données SQL et implémentant en grande partie le standard SQL92 et les propriétés ACID. Contrairement aux serveurs de bases de données comme MySQL ou PostgreSQL, sa particularité est de ne pas reproduire le schéma habituel client/serveur mais d’être intégré directement aux programmes en utilisant des fichiers de bases de données. D. Richard Hipp, le créateur de SQLite, a choisi de distribuer cette bibliothèque dans le domaine public.

Ses principales caractéristiques sont détaillées sur le site officiel ou encore sur wikipedia.
Cette bibliothèque a d’ailleurs aussi été adopté par Google Gears mais j’y reviendrais plus tard.

2. Utilité d’une BDD locale dans AIR

Puisque Adobe a décidé d’inclure SQLite dans AIR, c’est que la demande a du être forte et que les domaines d’applications sont assez nombreux.

En effet, cela va permettre dans un premier temps de concevoir des applications qui pourront fonctionner offline lorsque l’accès au réseau est indisponible. Par exemple, un client mail qui sauvegarde un mail à envoyer dans la base de données en attendant que la connexion soit rétablie.

Ca devient intéressant aussi si l’on souhaite récupérer l’intégralité (ou juste une partie) d’un serveur de BDD vers une BDD locale pour limiter les interactions client/serveur ou encore accélérer certaines requêtes ou opérations.

Un autre type d’utilisation peut être la sauvegarde des préférences utilisateurs d’une application dans le cadre d’une gestion multi-utilisateurs.

D’un point de vue plus général, il faut avoir en tête les différents avantages et inconvénients de se type de bases de données, identifier les enjeux de l’application , son public cible et son évolution afin de déterminer si il faut se tourner vers un serveur de BDD plutôt que la solution locale. Avant d’opter pour cette dernière, il est nécessaire de s’assurer que :

- Une seule personne et une seule application à la fois manipulent la BDD.
- L’application ne génère pas de trafics importants.
- L’application ne manipule pas de grandes quantités de données.
- La gestion des transactions n’est pas nécessaire.

Dans le cas contraire, mieux vaut alors se pencher vers un serveur distant.

3. Evolutions à prévoir

Encore une fois, il ne s’agit qu’une version beta, et des changements sont à prévoir dans les versions à venir.

D’une part, Adobe et Google ont annoncé qu’ils devraient alignés leurs API de manipulation de SQLite. Cela signifie que l’API d’AIR sera amené à changer et qu’il faudra donc modifier son code dans les applications développées avec la version beta. Je ne saurais conseillé alors d’externaliser dans une classe les accès aux données de vos programmes afin qu’aux prochains changements , uniquement cette classe devra être modifiée.
Vous trouverez d’ailleurs un example sur le blog de Brandon Nellis.

Voilà pour ce billet consacré aux BDD locales dans AIR. Il devrait être modifié lors des nouvelles versions de AIR si des changements ont lieu ou si quelques infos nécessaires ont été oubliés. N’hésitez donc pas à laisser un commentaire

Tags: AIR, Base de données, SQLite

Articles relatifs :

• L’API ‘Drag And Drop’ de AIR (3ème Partie) (4 commentaires)
• L’API ‘Drag And Drop’ de AIR (2ème Partie) (2 commentaires)
• L’API ‘Drag And Drop’ de AIR (1ère Partie) (8 commentaires)

Cet article a été posté le 11 juillet 2007 dans la catégorie AIR. Vous pouvez vous abonner aux commentaires grâce à ce flux : RSS 2.0. Vous pouvez laisser un commentaire ou faire un Trackback depuis votre site.