Stratégies d’utilisation des bases de données SQL

Adobe AIR 1.0 et les versions ultérieures

Une application peut accéder à une base de données SQL locale et l’exploiter de différentes manières. La conception de l’application peut varier en termes d’organisation du code, d’ordre et de synchronisation d’exécution des opérations, etc. Les techniques choisies peuvent affecter la simplicité du développement de votre application, par exemple, la facilité avec laquelle l’application pourra être modifiée dans les futures mises à jour. Elles peuvent également avoir un impact sur le bon fonctionnement de l’application du point de vue des utilisateurs.

Distribution d’une base de données pré-renseignée

Lorsque vous utilisez une base de données SQL locale AIR dans votre application, cette dernière attend une base de données présentant une certaine structure de tables, de colonnes, etc. Certaines applications s’attendent également à ce que certaines données soient pré-renseignées dans le fichier de la base de données. Créer la base de données au sein du code de l’application est un moyen de s’assurer que la base de données présente la structure appropriée. Lors du chargement de l’application, celle-ci vérifie la présence de son fichier de base de données dans un emplacement particulier. Si le fichier n’existe pas, l’application exécute un ensemble de commandes pour le créer, crée la structure de la base de données et renseigne les tables avec les données initiales.

Le code qui crée la base de données et ses tables est souvent complexe. Bien souvent, il n’est utilisé qu’une fois au début de la durée de vie d’une application installée, mais augmente tout de même la taille et la complexité de celle-ci. Au lieu de créer la base de données, sa structure et ses données par programmation, vous pouvez distribuer une base de données pré renseignée avec votre application. Pour distribuer une base de données prédéfinie, incluez le fichier de base de données dans le package AIR de l’application.

Comme tous les fichiers inclus dans ce package AIR, un fichier de base de données regroupé est installé dans le répertoire de l’application (celui représenté par la propriété File.applicationDirectory). Toutefois, les fichiers de ce répertoire sont en lecture seule. Servez-vous du fichier du package AIR en tant que base de données « modèle ». La première fois que l’utilisateur exécute l’application, copiez le fichier de base de données d’origine dans le Pointage vers le répertoire de stockage d’une application de l’utilisateur (ou dans un autre emplacement) et utilisez cette base de données dans l’application.

Recommandations concernant l’utilisation des bases de données SQL locales

Voici une liste de techniques conseillées qui permettront d’améliorer les performances, la sécurité et la simplicité de maintenance des applications lors de l’utilisation de bases de données SQL locales.

Création préalable des connexions à la base de données

Même si votre application n’exécute aucune instruction lors de son premier chargement, instanciez un objet SQLConnection et appelez sa méthode open() ou openAsync() en amont (par exemple après le démarrage initial de l’application) pour éviter les délais lors de l’exécution des instructions. Voir la section Connexion à une base de données.

Réutilisation des connexions à la base de données

Si vous accédez à une certaine base de données pendant l’exécution de votre application, gardez une référence à l’occurrence de SQLConnection et réutilisez-la dans toute l’application au lieu de fermer et de rouvrir la connexion. Voir la section Connexion à une base de données.

Choix préférentiel du mode asynchrone

Lors de l’écriture du code d’accès aux données, il peut être tentant d’exécuter les opérations de façon synchrone plutôt que de façon asynchrone car cela demande souvent un code plus court et moins complexe. Toutefois, comme nous l’avons vu à la section Utilisation des opérations de base de données synchrones et asynchrones, les opérations synchrones peuvent affecter les performances de façon évidente pour les utilisateurs et nuire à leur exploitation de l’application. Le temps nécessaire à l’exécution d’une seule opération varie d’une opération à l’autre et notamment en fonction de la quantité de données impliquées. Par exemple, une instruction SQL INSERT qui n’ajoute qu’une seule ligne à la base de données prend moins de temps qu’une instruction SELECT qui récupère des milliers de lignes de données. Toutefois, lorsque vous utilisez le mode synchrone pour exécuter plusieurs opérations, les opérations sont généralement enchaînées. Même si le temps nécessaire à chaque opération est très court, l’application se bloque jusqu’à ce que toutes les opérations synchrones soient terminées. En résultat, le temps cumulé des différentes opérations peut être suffisant pour bloquer votre application.

Utilisez les opérations asynchrones comme approche habituelle, en particulier dans le cas d’opérations impliquant un grand nombre de lignes. Une technique permet de diviser le traitement des vastes jeux de résultats de l’instruction SELECT. Cette technique est décrite à la section Récupération partielle des résultats d’une instruction SELECT. Cette technique ne peut cependant être utilisée qu’en mode d’exécution asynchrone. Utilisez uniquement les opérations synchrones lorsque vous ne pouvez pas obtenir certaines fonctionnalités avec la programmation asynchrone, lorsque vous avez pris en compte les baisses de performances que les utilisateurs de votre application rencontreront éventuellement et après avoir testé votre application de manière à connaître l’impact sur les performances. L’utilisation du mode d’exécution asynchrone peut impliquer un codage plus complexe. Toutefois, n’oubliez pas que le code ne doit être écrit qu’une seule fois alors que les utilisateurs emploient l’application de façon répétée, qu’elle soit rapide ou lente.

Dans la plupart des cas, l’utilisation d’une occurrence de SQLStatement distincte pour chaque instruction SQL à exécuter permet de mettre plusieurs opérations SQL en file d’attente à la fois, ce qui, en termes d’écriture du code, rend le code asynchrone similaire au code synchrone. Pour plus d’informations, voir la section Présentation du modèle d’exécution asynchrone.

Utilisation d’instructions SQL distinctes sans modification de la propriété text de l’occurrence de SQLStatement

Pour chaque instruction SQL exécutée plusieurs fois dans une application, créez une occurrence de SQLStatement distincte. Servez-vous de cette occurrence de SQLStatement chaque fois que cette commande SQL s’exécute. Supposons par exemple que vous développiez une application comprenant quatre opérations SQL différentes exécutées à plusieurs reprises. Dans ce cas, créez quatre occurrences de SQLStatement distinctes et appelez la méthode execute() de chaque instruction pour l’exécuter. Evitez d’utiliser une seule occurrence de SQLStatement pour toutes les instructions SQL, en redéfinissant chaque fois sa propriété text avant d’exécuter l’instruction.

Utilisation de paramètres d’instruction

Utilisez des paramètres pour SQLStatement. Ne concaténez jamais la saisie de l’utilisateur dans le texte de l’instruction. L’utilisation de paramètres sécurise votre application car elle empêche les attaques par injection de code SQL. Il est alors possible d’utiliser des objets dans les requêtes (au lieu d’utiliser uniquement des valeurs littérales SQL). Cela renforce également l’efficacité de l’exécution des instructions car ces dernières peuvent être réutilisées sans qu’il soit nécessaire de les recompiler chaque fois qu’elles sont exécutées. Voir la section Utilisation de paramètres dans des instructions.