La mercatique Microsoft nous fait croire que pour passer d’Access à SQL Server il suffit de trois clics dans un assistant et le tour est joué. Hélas, ceci conduit à des problèmes catastrophiques et des applications inutilisables. Certains éditeurs ont même été contraint de faire machine arrière et de redévelopper leurs applications devant le mécontentement de leurs clients…

Voyons donc quel est le problème… En fait tout part d’un concept fallacieux, celui de tables liées…

Faisons immédiatement la remarque suivante : la notion de table en tant qu’objet « physique » n’existe pas. En effet toute table ne peut en principe être attaquée que par une requête SQL. Une table étant un objet purement logique….

Pour comprendre toute la perversité de la notion de table liée il nous faut apprendre comment fonctionne les bases de données fichiers et celles qui sont en client/serveur.

Dans cet article :
http://sqlpro.developpez.com/cours/sgbdr/

Je dit notamment :

… il existe une différence fondamentale en matière d’exécution de ces requêtes. En fait dans le cadre d’un SGBD de type fichier, celui-ci exécute toujours la requête de manière locale tandis que dans un SGBD C/S ce dernier exécute la requête sur le serveur.
La différence est fondamentale en matière de congestion du trafic réseau… et il ne faut pas oublier qu’à la base, que se soit en fichier ou en C/S, tous les accès aux données se font par le biais de requêtes…

Puis je poursuit :

Pour comprendre la différence, voici un exemple simple. Une table de nom CLIENT contient 50 000 enregistrements de 200 octets chacun. La requête est la suivante :

SELECT * FROM CLIENT WHERE (CLI_NAME like ‘%CLINTON%’)

Dans un SGBD de type fichier, voici le flot de données :

* Le PC rapatrie depuis le serveur le fichier contenant la table CLIENT (Soit au minimum 50 000 x 200 octets (sans compter les index et le reste [1])
* Le PC traite localement la requête
* Le PC affiche le résultat (soit par exemple 5 lignes de 200 octets)

Dans un SGBD de type C/S, voici le flot de données :

* Le PC envoie au serveur le fichier texte de la requête (soit environ 50 octets)
* Le serveur exécute la requête sur la table CLIENT
* Le serveur renvoie au PC les données répondant à la requête (soit nos 5 lignes de 200 octets)
* Le PC affiche le résultat

Bilan de ces opérations :
SGBD fichier : environ 10 001 000 octets ont été véhiculé sur le réseau
SGBD C/S : environ 1 050 octets ont été véhiculés sur le réseau

Dans ce cas, le rapport est de près de 1/10000 en faveur du C/S…

Cependant cet exemple n’est valable que pour les SGBDR fichier basé sur le modèle XBase comme DBase, Paradox, Clipper, Foxbase (FoxPro). Ce modèle propose de découper une base de données en de multiples fichiers de la manière suivante (par exemple pour Paradox) :
1) une table est un ensemble de n fichier
2) les fichiers d’une tables sont :

• le fichier des données de la table (*.db)
• les fichiers d’index : l’index primaire étant composé d’un seul fichier (*.px) et chaque index secondaires de 2 (*.xNN et *.yNN ou N est un nombre de 0 à 9)
• un éventuel fichier de contrôle de validité (*.val)
• un éventuel fichier contenant les BLOBS (*.mb)

Dans un système de base de données fichier, c’est chaque client qui exécute chacun des requêtes. Tant est si bien que dans ce modèle, faire une requête consiste à demander au serveur de lire les fichiers adéquats à traiter les requêtes (les fichiers sont envoyés depuis le serveur au client).

Par exemple la requête :

SELECT Nom, Prenom 

FROM   Client C 

       INNER JOIN Facture F 

             ON C.CliNum = F.CliNum 

WHERE Datefacture = CURRENT_DATE

Nécessite par exemple d’envoyer les fichiers suivants :

• pour Client : Client.db
• pour facture : Facture.db ainsi que Facture.x03 et Facture.y03 si la date de facture est indexée et que c’est l’index 03 qui contient cette information.

Mais pour que ceci se réalise correctement au niveau de la concurrence il faut aussi placer des verrous. Toute opération de lecture ou d’écriture dans une base oblige à poser des verrous :

• Verrous de lecture afin d’interdire que quelqu’un d’autre vienne modifier les données ou pire, modifier la structure de la table simultanément,
• Verrous d’écriture afin d’interdire que quelqu’un d’autre vienne lire ou modifier données ou structure de la table simultanément

C’est pourquoi il y a aussi des fichiers de contrôle de verrouillage centralisé au niveau du serveur…

Mais le modèle Access est différent du modèle XBase… Ainsi pour Access une base de données est constituée d’un seul fichier. Tant est si bien que lorsqu’il faut aller écrire une seule information ou faire une extraction (SELECT) il faut se payer le transport de toute la base entre le serveur et le client….
D’où les temps de réponse hallucinament long, par rapport à n’importe quel autre SGBDR !!!!!

J’ai d’ailleurs l’habitude de dire qu’Access est le plus mauvais de tous les SGBDR :

• son modèle fichier monobase induit les temps de réponse les plus longs de tous les SGBDR,
• son niveau de SQL n’est même pas conforme à la norme SQL 1 (par exemple le LIKE ou la façon de faire des JOIN…)

Conscient de cela, Microsoft à planifié l’abandon de ce moteur de base de données depuis des années et ne fait pratiquement plus de R&D dessus. Ainsi il ne sera pas porté sur les futurs OS et ne passera pas le cap du 64 bits.
En revanche MS insiste pour que les utilisateurs d’Access passent à SQL Server, notamment par le biais de la version gratuite Express…
Grande différence aussi : SQL Server Express est gratuit, alors qu’Access est payant !

Access en tant que client d’un serveur SQL

Maintenant Access contient aussi les IHM (fiches, états…). Si votre version est centralisée, il faut alors véhiculer les fiches et les états nécessaires à l’activité du poste client depuis le serveur. D’où les flux entre le serveur et les clients.

Le problème des tables liées

La notion de table liée permettant de reproduire le modèle des tables Access dans le serveur SQL. Mais si vous utilisez cela, alors c’est comme si vous reproduisiez le fonctionnement d’Access avec SQL Server. En effet au lieu de demander au serveur de servir l’infime partie des données qui vous intéresse, vous lui imposer de travailler toutes les tables en SELECT *.

Voyons notre exemple (identique au précédent) :

SELECT Nom, Prenom 

FROM   Client C 

       INNER JOIN Facture F 

             ON C.CliNum = F.CliNum 

WHERE Datefacture = CURRENT_DATE

Avec un accès direct au serveur (sans table liée) l’envoi de la requête ne représente que quelques octets. Le serveur va, lui, renvoyer uniquement les données des colonnes Nom et Prenom de la table client et seulement pour les quelques lignes qui répondent au filtre WHERE…
Malheureusement, avec la technique des tables liées, le client intercepte au niveau d’Access l’ordre SQL et le décompose en deux ordres distincts :

• SELECT * FROM Client
• SELECT * FROM Facture

Le serveur renvoie alors toutes les lignes et toutes les colonnes de deux tables vers le client… Puis la jointure comme le filtre WHERE sont alors réalisée par le client.
D’ou des temps de réponse à nouveau horriblement longs malgré l’utilisation d’un serveur de base de données comme MS SQL Server.

Vous venez de comprendre le piège… Autrement dit, si vous voulez des performances avec un serveur SQL, on ne doit jamais faire d’accès aux tables, donc pas de « tables liées »… On fait des requêtes SQL.

C’est pourquoi au tout début j’ai parlé de d’une table comme étant un objet logique. En effet dans un serveur SQL, le fichier contenant les données contient toutes les tables réparties en différentes pages (dans SQL Server les pages font toujours 8 Ko). C’est le moteur relationnel qui accède aux pages qui l’intéresse pour traiter la requête et ne renvoie que les colonnes des lignes qui répondent à la demande.

Autrement dit faites des requêtes SQL et abandonnez toute notion de table. La notion de table n’est qu’une représentation logique de l’information !

-------- 

Frédéric Brouard, SQLpro - ARCHITECTE DE DONNÉES, http://sqlpro.developpez.com/ 

Expert bases de données relationnelles et langage SQL. MVP Microsoft SQL Server 

www.sqlspot.com : modélisation, conseil, audit, optimisation, tuning, formation 

* * * * *  Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence  * * * * *