8
Chapitre 2. Architecture de SQL Server
Figure 2.1 — Architecture client-serveur
Dans le schéma de la figure 2.1 extrêmement simplifié, nous avons un résumé de
l’architecture client-serveur de SQL Server. Une application cliente (comme SQL
Server Management Studio – SSMS) envoie des requêtes en SQL. L’unique manière
d’obtenir des données, est de passer par le langage SQL. SQL Server n’est pas un serveur de fichiers : il stocke et protège ses données à l’aide de ses mécanismes internes,
et n’offre aucun moyen d’accéder directement aux données des bases. La seule façon
d’obtenir des lignes de table, est d’en faire la demande au serveur, à l’aide d’ordres
SQL. Ces ordres sont transmis par une bibliothèque cliente, comme ODBC, OLEDB
ou ADO.NET, dont la tâche est de faire la transition entre les langages procéduraux
clients et les bibliothèques de bas niveau en offrant une couche d’abstraction. Cette
bibliothèque adresse la requête à une bibliothèque réseau (net-library) adaptée aux
protocoles réseaux utilisés (de nos jours, principalement TCP-IP), qui elle-même la
transmet par paquets à travers la couche physique codée dans le protocole réseau de
SQL Server, nommé TDS (Tabular Data Stream), un protocole initialement développé par Sybase 1 et que SQL Server partage avec ce SGBDR (bien que l’implémentation particulière de Microsoft soit nommée MS-TDS 2 ).
Du côté serveur, SQL Server est composé de deux principaux moteurs, respectivement le moteur relationnel, relational engine (ou moteur de requête, query engine),
et le moteur de stockage, storage engine, qui contiennent chacun différents modules.
La requête provenant du client est prise en charge par le moteur relationnel, qui évalue le code SQL, vérifie les métadonnées et les privilèges, passe par une phase d’optimisation pour produire un plan d’exécution (query plan) optimisé, et gère
1. Jusqu’à la version 6.5 comprise, SQL Server était un développement partagé entre Sybase et
Microsoft. La version 7 fut totalement réécrite par Microsoft.
2. Le protocole MS-TDS est maintenant décrit dans le MSDN : http://msdn.microsoft.com/enus/library/cc448436.aspx
Chapitre 2. Architecture de SQL Server
Figure 2.1 — Architecture client-serveur
Dans le schéma de la figure 2.1 extrêmement simplifié, nous avons un résumé de
l’architecture client-serveur de SQL Server. Une application cliente (comme SQL
Server Management Studio – SSMS) envoie des requêtes en SQL. L’unique manière
d’obtenir des données, est de passer par le langage SQL. SQL Server n’est pas un serveur de fichiers : il stocke et protège ses données à l’aide de ses mécanismes internes,
et n’offre aucun moyen d’accéder directement aux données des bases. La seule façon
d’obtenir des lignes de table, est d’en faire la demande au serveur, à l’aide d’ordres
SQL. Ces ordres sont transmis par une bibliothèque cliente, comme ODBC, OLEDB
ou ADO.NET, dont la tâche est de faire la transition entre les langages procéduraux
clients et les bibliothèques de bas niveau en offrant une couche d’abstraction. Cette
bibliothèque adresse la requête à une bibliothèque réseau (net-library) adaptée aux
protocoles réseaux utilisés (de nos jours, principalement TCP-IP), qui elle-même la
transmet par paquets à travers la couche physique codée dans le protocole réseau de
SQL Server, nommé TDS (Tabular Data Stream), un protocole initialement développé par Sybase 1 et que SQL Server partage avec ce SGBDR (bien que l’implémentation particulière de Microsoft soit nommée MS-TDS 2 ).
Du côté serveur, SQL Server est composé de deux principaux moteurs, respectivement le moteur relationnel, relational engine (ou moteur de requête, query engine),
et le moteur de stockage, storage engine, qui contiennent chacun différents modules.
La requête provenant du client est prise en charge par le moteur relationnel, qui évalue le code SQL, vérifie les métadonnées et les privilèges, passe par une phase d’optimisation pour produire un plan d’exécution (query plan) optimisé, et gère
1. Jusqu’à la version 6.5 comprise, SQL Server était un développement partagé entre Sybase et
Microsoft. La version 7 fut totalement réécrite par Microsoft.
2. Le protocole MS-TDS est maintenant décrit dans le MSDN : http://msdn.microsoft.com/enus/library/cc448436.aspx