Discussion :

[Chtulus]

Bonjour,

Je travail avec Access2003 en client et SQL Server 2000 en... serveur.

J'avoue que je n'arrive pas bien à saisir le fonctionnement C/S. J'ai lu pas mal de truc dans les FAQ et tuto... mais je reste sur ma faim.

Pour moi, lorsque les tables sont liées, il y a bien une copie de la Base du serveur sur le poste client.
Lorsque je traite une requête, se sont bien les ressources de la machine client qui sont utilisées (Access est un SGBD fichiers) ?
Lorsque la requête en revanche passe par une vue SQL, se sont les ressources du serveur qui sont cette fois seront utilisées ?

Seulement la ou je comprends encore moins et si tout cela est juste, lorsque je traite une requête normale, on peut voir la requête tourner sur le serveur, là je suis un peu perdu et mon chef n'est pas d'accord avec moi... Bien que sous Access, il y a des actualisations des lien OLE/DDE et ODBC et des mises à jour (Outils/Options/Avancée), à quoi correspondent-elles ?

On se pose la question surtout pour comprendre le temps de réponse des requêtes.

J'espére avoir étais clair sur mes questions ?

[pacmann]

Salut !

Bon, je tente ma chance. Ce n'est que mon interprétation...
La table liée, ce n'est rien de physique. C'est comme un serveur lié sur SQL Server.
La différence entre ça et un accès "direct" à la table sous SQL serveur, c'est que ça te permet de demander des croisement de données entre une table locale access et la table liée distante.

Qu'est ce qui me pousse à dire ça ?
Ben si il y avait un stockage intermédiaire en local, ça provoquerait un gros risque de désynchronisation...

Je ne sais pas dans quel cas vous avez des problèmes de perf, mais si vous faites de jointures entre les tables locales et les tables liées, c'est normal. La problématique est d'ailleurs toujours la même sur les requêtes distribuées...
L'esprit d'optimisation de ce genre de requêtes n'est pas du tout le même que pour les requêtes sur un serveur unique (chacun ne dispose que de la moitié des infos pour créer son exec plan...).

Et concernant le rafraîchissement des liens, il me semble que c'est juste pour forcer Access à vérifier que les tables distantes existent toujours, et à mettre à jour les méta-infos les concernant...

(Ah, j'adore donner mon avis sur des trucs que je ne connais pas )

[Chtulus]

Et ben en fait, il n'y a que des tables liées... aucune locale...

Je viens de renvoyer des scripts afin d'enlever les verrous (s'il en existe) sur les tables, par le NOLOCK pour les performances.

A voir, mais je ne comprends toujours pas bien ce lien entre le client et le serveur, qui traite quoi et quelles ressources sont donc utilisées ?

[pacmann]

Euh, dans ce cas, ça te sert à quoi de faire des tables liées ????

[Chtulus]

En fait l'application était déjà en place quand je suis arrivée.

Le Serveur est parti () depuis peu du côté de Lille et nous autres sommes restés à Lyon... avec Access. Le fait de lier les tables permet de voir les données si besoin est. Les utilisateurs ne connaissant pas le SQL, le travail se fait en QBE...

Sauf pour moi, quoi

[Chtulus]

En réfléchissant un peu, j'en suis arrivé aussi au niveau des droits.

Même avec des restrictions on peut quand même faire tourner les requêtes sans autorisations d'accés aux données dans la base (J'ai pas dû être très clair, ou j'ai peut-être mal formulé là ).

D'un autre côté pour attaquer directement le serveur (Par VBA par exemple et les liens ODBC), des droits spécifiques doivent donc être validés...

Je reste perdu dans ma réflexion...

[SQLpro]

Pour moi, lorsque les tables sont liées, il y a bien une copie de la Base du serveur sur le poste client.
Lorsque je traite une requête, se sont bien les ressources de la machine client qui sont utilisées (Access est un SGBD fichiers) ?
Lorsque la requête en revanche passe par une vue SQL, se sont les ressources du serveur qui sont cette fois seront utilisées ?

La notion de table lié n'a aucune influence. Elle n'est intéressante que dans le cas d'un serveur (C/S).
D'ailleurs la notion de "table" en elle même est idiote car toute table ne peut en principe être attaquée que par une requête SQL. Une table étant un objet logique....

Pour comprendre tout cela reprenons depuis le début !

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 le requête :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
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...

Seulement la ou je comprends encore moins et si tout cela est juste, lorsque je traite une requête normale, on peut voir la requête tourner sur le serveur, là je suis un peu perdu et mon chef n'est pas d'accord avec moi... Bien que sous Access, il y a des actualisations des lien OLE/DDE et ODBC et des mises à jour (Outils/Options/Avancée), à quoi correspondent-elles ?

Ce ne sont pas les données qui "tournent" sur le serveur, mais les activités de mise en place des verrous, et l'écriture finale des données.

On se pose la question surtout pour comprendre le temps de réponse des requêtes.

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'ailleur 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.

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 un exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
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, avec un serveur SQL on ne fait pas 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 !

A +

[Chtulus]

Salut,

Poufff !!! Ben voilà une réponse qui répond plus que fortement à mes questions.

http://sqlpro.developpez.com/cours/sgbdr/

Je l'avais déjà lu, tu penses bien, mais j'avais un peu de mal à établir une relation entre mes questions et tes explications. Parfois, on reste sur ces positions avec le mode oeillères...

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

Ca aussi je le savais déjà, j'ai eu l'occasion de te voir te déchainer sur Access moults fois...

Pour le reste, je trouve que beaucoup d'entreprises on encore se mode de fonctionnement, certes cela tend à changer mais bon, étant d'une SSII, j'ai l'occasion de voir beaucoup de truc bizarrrrrrr....

Encore merci beaucoup pour ces explications

Toujours un plaisir...

[SQLpro]

Le malheur veut que la formation en France en matière de SGBD relationnel et de modélisation de données soit la plus pauvre du monde. D'où des utilisations catastrophique des outils de type SGBDR !!!

Et je suis bien placé pour le savoir. J'enseigne en effet aux Arts & Métiers et dans une école d'ingénieur, tout en pilotant mon entreprise dans laquelle je fais de la formation professionnelle (50% de mon activité), de l'audit, du conseil....
C'est dire si je voit le niveau catastrophique de ce qui est fait !

A +

[BRODU]

Bonjour

Merci @SQLPro pour ton explication, elle est claire et précise.

Je savais que Access n'était pas performant, mais maintenant je sais exactement pourquoi ce qui est mieux pour convaincre lorsque cela est nécessaire.