Les nouveautés de Microsoft Access 2010

Dans un précédent message sur les forums de developpez.com, Maxence Hubiche annonçait l'arrivée des champs calculés au sein des tables de Microsoft Access 2010. Bien que la méthodologie Merise préconise d'exclure les données calculées des schémas, les SGBD évolués tels que SQL Server ont introduit des fonctionnalités permettant le stockage des calculs dans les tables afin de soulager les requêtes lorsque les opérations sont trop complexes ou fréquemment évaluées. A travers quelques tests nous vous proposons d'évaluer la pertinence de cette nouvelle fonctionnalité débarquant dans Microsoft Access.

Démonstration en vidéo : si vous le souhaitez, vous pouvez consulter la vidéo de Maxence Hubiche traitant des champs calculés dans une table Access : https://mhubiche.developpez.com/videos/access-2010-nouveautes-champs-calcules/

Pour illustrer nos propos, nous allons travailler sur l'exemple d'une table rassemblant les lignes des commandes d'une société de vente de produits ménagers.

Voici ci-dessous la structure habituelle pour gérer ces données :

Le calcul du prix total d'une ligne de commande (Prix HT * Qte) est alors obtenu par la requête suivante :

SELECT 
  tblLigneCommande.IDCommande, 
  tblLigneCommande.IDProduit, 
  tblLigneCommande.Qte, 
  tblLigneCommande.PrixHT, 
  [Qte]*[PrixHT] AS TotalLigne
FROM tblLigneCommande;

Sous Microsoft Access 2010, un nouveau type de champ fait son apparition, il s'agit du champ calculé destiné à stocker le calcul dans la table. Voici la nouvelle définition de la table : :

La propriété Expression contient la règle de calcul à appliquer. Inutile de se soucier de Result Type (type du champ), Access adoptera le type adéquat en fonction des champs et des fonctions utilisés pour les calculs (si vous manipulez du texte, alors Result Type sera du texte, si vous manipulez des dates, alors ce sera une date).

La requête d'affichage des lignes de commande se trouve donc allégée :

SELECT *
FROM tblLigneCommande;

Notons que si vous utilisez DAO pour créer vos champs, le nouveau type est défini via les deux éléments suivants :

• Le type passé à la méthode CreateField qui définit le type de retour attendu (texte, entier, etc.)
• La propriété Expression qui correspond à la règle de calcul à appliquer

Exemple :

Dim oFld As DAO.Field
Dim oTbl As DAO.TableDef

Set oFld = oTbl.CreateField("TotalLigne", dbCurrency)
oFld.Properties("Expression").Value = "[Qte]*[PrixHT]"

Bien entendu, un tel stockage n'est pas sans incidence et nous avons tenté d'en déterminer les répercussions sur l'ensemble de la base de données.

La première question posée consistait à déterminer si la donnée était effectivement stockée ou bien seulement son opération mathématique. Un test avec 10000 enregistrements amène le constat suivant :

• Taille de la base de données avec la table tblLigneCommande vide : 412 Ko
• Taille de la base de données avec la table tblLigneCommande remplie et possédant un champ LigneCommande de type Currency avec la valeur stockée : 912 Ko
• Taille de la base de données avec la table tblLigneCommande remplie et possédant un champ LigneCommande de type Calculated : 1284 Ko

Les tests ont été répétés des dizaines de fois avec compactage entre chaque étape. La différence de volume entre les deux solutions est difficilement explicable et dans le cas présent, le champ calculé occupe à lui seul près de 45% du volume total de la table tblLigneCommande. Ne pouvant réellement pas comprendre le mode de stockage de ce nouveau champ, nous nous sommes intéressés dans un second temps aux performances. L'insertion via recordset de 10000 enregistrements dans la table tblLigneCommande dépourvue de champ calculé est exécutée en 9.04 secondes (moyenne sur 10 essais) alors que les mêmes tests avec un champ calculé affiche une moyenne de 13.06 secondes (toujours en 10 essais).

D'autre part, sur ces 10000 enregistrements, il n'y a pas de différence significative entre les deux requêtes données en début de ce chapitre correspondant toutes les deux à des structures différentes de la table tblLigneCommande. Sans champ calculé, la requête est exécutée 1000 fois en 7,94 secondes contre 7,92 dans le second cas.

Bien entendu, la règle de calcul utilisée ici est très simple, ce qui pourrait justifier des écarts aussi minimes et donc cacher l'avantage des champs calculés. Nous pourrions répondre par l'affirmative si toutefois les champs calculés n'avaient pas une limitation majeure : à l'heure actuelle, il est impossible de faire référence à d'autres enregistrements que celui pointé par le calcul. En d'autre termes, impossible de faire de moyennes, de sommes, de sous requêtes, ni même d'appel à des fonctions VBA personnalisées. Quel peut donc être l'intérêt de stocker une donnée qui semble occuper un volume de stockage conséquent et dont le calcul ne relève d'aucune complexité ? A priori, aucun.

Pour conclure, et en l'état de l'avancement du développement d'Office 2010, c'est-à-dire sur la Technical Preview, les champs calculés apparaissent plutôt comme un gadget qui va distraire le débutant en dé-normalisant inutilement sa base de données rendant la maintenance et l'évolution vers d'autres plateformes encore plus difficile. Le développeur préfèrera sûrement cataloguer cette fonctionnalité avec les champs multi-valués d'Access 2007 dans le lot des "peu recommandés".