Expose SQL
Expose SQL
Expose SQL
Plan
Introduction………………………………………………………… 02
I. Historique………………………………………………………. 03
Conclusion…………………………………………………………… 33
Références…………………………………………………………… 39
Page 1
Architecture client serveur – Exposé : Langage SQL
Introduction
Devant l’accroissement des collectes d’informations électroniques en vue de diverses
exploitations, il devenait urgent de mettre en place un système capable d’organiser et de
stocker un nombre considérable d’informations.
En 1970, ce besoin a été vécu dans les laboratoires d’IBM et a donné naissance à un
système capable d’entretenir les fichiers contenant les informations tout en masquant les
détails complexes et fastidieux liés à leurs gestions, permettant ainsi à l’utilisateur
d’accéder simplement aux informations via un langage d’interrogation. Cette première
étape a introduit de nouvelles notions comme les bases de données, le modèle relationnel
et le système de gestion de base de données.
Par la suite diverses sociétés ont proposé leur solution de gestion des données, leur langage
pour l’extraction des données.
Le langage SQL (Structured Query Language) (Langage de requêtes Structuré) est le fruit
d’années de réflexion sur la problématique de manipulation des données. Formalisé et
normalisé, il est né dans les années 1980 et a été rapidement adopté par la majorité des
éditeurs. Ses dernières normalisations l’ont fait s’orienter vers ce que l’on appelle
désormais le relationnel objet, c’est-à-dire l’introduction de certains principes de la
programmation objet au sein des bases de données relationnelles.
Après un bref historique du langage SQL, nous donnerons des syntaxes de quelques
commandes pour aboutir à une comparaison de certaines fonctions dans des SGBD.
Page 2
Architecture client serveur – Exposé : Langage SQL
I. Historique
La théorie sur laquelle repose SQL a été énoncée par le professeur Edgar Frank Codd
(1924-2003), un mathématicien d’Oxford, alors qu’il travaillait comme chercheur pour
IBM au laboratoire de San Jose. L’article « A relational model of data for large shared data
banks », publié en juin 1970 dans la revue Association for Computing Machinery, fait
toujours office de référence et a initié tous les travaux qui ont suivi et qui perdurent.
Codd voulait créer un système où l’interrogation des données utilisait le vocable anglais.
Les travaux de la NASA (National Aeronautics and space Adminstration) (Administration
Nationale de l’aéronautique et de l’espace), sur la base de données modélisant les rochers
rapportés du voyage sur la lune, a aidé au développement de ce langage en lui donnant de
la crédibilité.
Dès 1974, IBM entamait un prototype de bases de données relationnelles appelé System/R.
Ce projet se termina en 1979, prouvant ainsi la viabilité d’un tel système. Le langage de
programmation utilisé par IBM pour System/R fut appelé SEQUEL (Structured English
Query Language) rebaptisé par la suite SQL (Structured Query Language).
Comme tout langage, SQL a eu ses concurrents, le plus connu fut QUEL du SGBD Ingres
du début des années 1980.
Page 3
Architecture client serveur – Exposé : Langage SQL
Cette première mouture, appelée SQL86 ou SQL1 (une centaine de pages), était le résultat
de compromis entre constructeurs, mais fortement influencée par le dialecte d’IBM.
En 1989, d’importantes mises à jour furent faites en matière d’intégrité référentielle (ANSI
X3.135-1989 et ISO/IEC 9075:1989).
La deuxième norme (appelée SQL92 ou SQL2 d’un volume d’environ 600 pages) fut
finalisée en 1992. Elle définissait quatre niveaux de conformité : le niveau d’entrée (entry
level), les niveaux intermédiaires (transitional et intermediate levels) et le niveau supérieur
(full level). Les langages SQL des principaux éditeurs sont tous conformes au premier
niveau et ont beaucoup de caractéristiques relevant des niveaux supérieurs.
Les groupes de travail X3H2 de l’ANSI et WG3 de l’ISO se penchèrent, à partir de 1993,
sur les extensions à apporter à la précédente norme. Les optimistes prévoyaient SQL3 pour
1996… Rien ne se passa comme prévu. Il fallut attendre 1999 pour voir établir le projet «
SQL:1999 » appelé communément SQL3 (volume de 1 600 pages à l’époque). Ce retard
fut probablement dû aux difficultés des nombreux protagonistes (Oracle, IBM, Microsoft,
Digital, Computer Associates, etc.) à remettre en cause leur mode de pensée, et aux risques
qu’ils pressentaient de ne pouvoir assurer la compatibilité des bases de leurs clients.
Les évolutions de l’ancienne norme ne sont pas limitées aux seules extensions objet. Bien
d’autres mécanismes ont été introduits dans ce projet (géographie, temps, réel, séries
temporelles, multimédia, OLAP, données et routines externes).
SQL:1999 est désormais une norme (au sens International Standard de l’ISO) qui apparaît
dans le domaine Information technology – Database languages – SQL. Elle porte
principalement la référence ISO/IEC 9075.
Peu après, une nouvelle version de SQL (SQL:2003), apportant des modifications
mineures, apparut. Ses apports concernent l’auto-incrément des clés, de nouvelles
fonctions dites analytiques, les colonnes calculées, l’ordre MERGE combinant UPDATE et
INSERT et surtout un support complet de XML.
Page 4
Architecture client serveur – Exposé : Langage SQL
Depuis 2006, des modules ont été révisés et publiés, mais il n’y a pas encore à proprement
parler de norme.
SQL-86 ou
1986 ISO/CEI 9075:1986 Édité par l'ANSI puis adopté par l'ISO en1987.
SQL-87
SQL-89 ou
1989 ISO/CEI 9075:1989 Révision mineure.
SQL-1
SQL-92 ou
1992 ISO/CEI 9075:1992 Révision majeure.
SQL2
SQL est un langage composé de deux parties bien distinctes et, dans ces deux parties, de
diverses subdivisions.
La seconde partie est constituée d’un langage plus classique de type procédural dans lequel
on retrouve les notions de fonctions, méthodes, procédures, etc.
• CLI (Call Level Interface) : en fait, des « API » destinées à piloter des objets encapsulant
des données dans des langages hôtes par l’intermédiaire, la plupart du temps, d’un
middleware (BDE, dbExpress de Borland, OBDC, ADO, OleDB de Microsoft,
JDBC, etc.).
Page 7
Architecture client serveur – Exposé : Langage SQL
Page 8
Architecture client serveur – Exposé : Langage SQL
Page 9
Architecture client serveur – Exposé : Langage SQL
Page 10
Architecture client serveur – Exposé : Langage SQL
Exemple
COMMANDE (NUM, CNOM, PNOM, QTE)
PRIX (PNOM, FNOM, COUT)
FOURNISSEUR (ID, FNOM, VILLE, SEXE, EMAIL)
CREATE TABLE COMMANDE
(NUM INT UNIQUE,
CNOM CHAR(20) NOT NULL,
PNOM CHAR(20) NOT NULL,
QTE DEC (7,2)
) ;
CREATE TABLE PRIX
(PNOM CHAR(20) NOT NULL,
FNOM CHAR(20) NOT NULL,
COUT INT
) ;
CREATE TABLE FOURNISSEUR
(ID INT PRIMARY KEY,
FNOM VARCHAR(20) NOT NULL,
VILLE CHAR(20),
SEXE CHAR(20)
CONSTRAINT CK_SEXE CHECK (SEXE ='Masculin' OR SEXE = 'Féminin'),
EMAIL VARCHAR(50) NOT NULL UNIQUE,
CONSTRAINT CK_EMAIL CHECK (EMAIL LIKE ('%@%.%'))
) ;
Page 11
Architecture client serveur – Exposé : Langage SQL
SELECT n’élimine pas les duplications. Pour les éliminer, on utilise la clause DISTINCT
ou UNIQUE: si, dans le résultat, plusieurs lignes sont identiques, une seule sera conservée.
Page 13
Architecture client serveur – Exposé : Langage SQL
La clause FROM donne la liste des tables participant à l'interrogation. Il est possible de
lancer des interrogations utilisant plusieurs tables à la fois.
La clause WHERE permet de spécifier quelles sont les lignes à sélectionner dans une table
ou dans le produit cartésien de plusieurs tables. Elle est suivie d'un prédicat (expression
logique ayant la valeur vrai ou faux) qui sera évalué pour chaque ligne. Les lignes pour
lesquelles le prédicat est vrai seront sélectionnées.
Le littoral qui suit LIKE doit être une chaîne de caractère avec éventuellement des
caractères jokers.
_ ___ remplace 1 caractère exactement
_ _%_ remplace une chaîne de caractères de longueur quelconque, y compris de longueur
nulle
Page 14
Architecture client serveur – Exposé : Langage SQL
IV.2.1.3.3 Jointure
Quand on utilise deux tables ou plus, on effectue en réalité des jointures entre ces
tables.
Une jointure permet donc de combiner les colonnes de plusieurs tables.
Lorsque la jointure entre tables s'effectue en imposant l'égalité des valeurs d'une colonne
d'une table à une colonne d'une autre table, on parle de jointure naturelle ou équi-jointure.
On trouve aussi des jointures d'une table sur elle-même. On parle alors d'auto-jointure. Il
arrive que l'on doive procéder à des jointures externes, c'est-à-dire joindre une table à une
autre, même si la valeur de liaison est absente dans une table ou l'autre. Dans certains cas,
on peut procéder à des jointures hétérogènes, c'est-à-dire que l'on remplace le critère
d'égalité par un critère d'inégalité ou de différence.
Exemple :
SELECT a.PNOM, COUT, FNOM FROM PRIX AS a
JOIN COMMANDE AS b ON a.PNOM = b.PNOM -- condition de jointure
WHERE CNOM = ’Jean’ -- condition de sélection
Page 15
Architecture client serveur – Exposé : Langage SQL
SELECT FNOM FROM PRIX WHERE PNOM = ‘BRIQUE’ AND COUT <
(SELECT AVG (COUT) FROM PRIX WHERE PNOM = ‘Brique’)
Cette clause permet de préciser les attributs de partitionnement des relations déclarées dans
la clause FROM.
Elle se place juste après la clause WHERE, ou après la clause FROM si la clause WHERE
n'existe pas.
Requête : Les produits fournis et leur coût moyen pour les fournisseurs dont le siège est à
Cotonou seulement si le coût minimum du produit est >1000
Les lignes constituant le résultat d'un SELECT sont obtenues dans un ordre indéterminé.
La clause ORDER BY précise l'ordre dans lequel la liste des lignes sélectionnées sera
donnée.
ORDER BY exp1 [DESC], exp2 [DESC], ...
L'option facultative DESC donne un tri par ordre décroissant. Par défaut, l'ordre est
croissant.
Page 17
Architecture client serveur – Exposé : Langage SQL
Avec Oracle:
SELECT PNOM, COUT FROM PRIX WHERE ROWNUM <= 10
Exemple :
INSERT INTO PRIX (PNOM, FNOM, COUT)
VALUES (“Bois”, “PAUL”, 20000)
Page 18
Architecture client serveur – Exposé : Langage SQL
La commande UPDATE permet de modifier les valeurs d'un ou plusieurs champs, dans
une ou plusieurs lignes existantes d'une table.
UPDATE nom-table
SET {nom-col = {expression | (subquery) } [ (nom-col [, nom-col…]) = (subquery) }
[WHERE condition]
Mises à jour des attributs cités des lignes qui vérifient la condition, ou de toutes les lignes
si la condition est omise.
Suppression des lignes qui satisfont la condition. Pas de condition, suppression de toutes
les lignes
La gestion des droits d’accès aux tables est décentralisée. Chaque créateur de table obtient
tous les droits d’accès à cette table en particulier le droit d’effectuer la sélection
(SELECT), l’insertion (INSERT) la suppression (DELETE), la mise à jour (UPDATE) et
aussi de référencer la table dans une contrainte avec la clause REFERENCE. Il peut
ensuite passer ses droits sélectivement à d’autres utilisateurs ou à tout le monde (PUBLIC).
Un droit peut être passé avec le droit de le transmettre ou non. C’est la clause WITH
GRANT OPTION
Suppression du privilège :
- Pour l’utilisateur nommé dans REVOKE
- Aux autres utilisateurs de la base à qui l’utilisateur nommé avait
propagé le privilège (en utilisant son droit WITH GRANT OPTION)
Les transactions sont des séquences de tâches s'effectuant dans un ordre logique par
l'intermédiaire de l'utilisateur ou d'une automatisation.
Les tâches peuvent être essentiellement des commandes DML : d'insertion (INSERT), de
suppression (DELETE) ou de modification (UPDATE) d'objets dans une base de données.
Page 20
Architecture client serveur – Exposé : Langage SQL
Ces diverses tâches peuvent être annulées en cours d'exécution puisqu'elles possèdent un
commencement et une fin.
COMMIT [WORK];
enregistre les modifications produites par des transactions.
SAVEPOINT nom_point;
insère un point de sauvegarde dans la liste de transactions, servant en conjonction avec
ROLLBACK pour une annulation jusqu'à un point précis.
Transactions...
SAVEPOINT nom_point
Transactions...
ROLLBACK TO nom_point;
Exemple
BEGIN TRANSACTION MYTRAN
INSERT INTO COMMANDE (NUM, PNOM, CNOM, QTE)
VALUES (1, 'TOLES', 'JEAN', 30000)
Page 21
Architecture client serveur – Exposé : Langage SQL
Les procédures stockées sont conservées dans la base de données dans une forme
exécutable et sont capables d'appeler d'autres procédures ou fonctions comme d'être
appelées par d'autres programmes.
A l'instar des procédures des langages de programmation, outre qu'elles soient composées
de diverses instructions, les procédures stockées sont capables de recevoir des paramètres
d'entrée et de retourner des valeurs en sortie.
Page 22
Architecture client serveur – Exposé : Langage SQL
AS instructions_SQL...
GO
La clause FOR REPLICATION indique que la procédure stockée doit être exécutée lors
de la modification de la table concernée par un processus de réplication.
Page 23
Architecture client serveur – Exposé : Langage SQL
La clause IN est utilisée pour spécifier une valeur pour l'argument en appelant la
procédure.
-- SQL Server
EXECUTE Procedure @Parametre = Valeur, ..., @ParametreN = ValeurN
-- Oracle
CALL Procedure(Valeur, ..., ValeurN)
Exemple
-- Instruction pour SQL Server
CREATE PROCEDURE ajout_enregistrement
@proc_pnom char(20),
@proc_fnom char(20),
@proc_cout int
AS
INSERT INTO PRIX (pnom, fnom, cout)
VALUES (@proc_pnom, @proc_fnom, @proc_cout)
GO
-- Instruction pour Oracle
CREATE PROCEDURE Ajout_Enregistrement (
proc_pnom char(20),
proc_fnom char(20),
proc_cout int
)
IS
BEGIN
INSERT INTO PRIX (pnom, fnom, cout)
VALUES (proc_pnom, proc_fnom, proc_cout
END;
-- Utilisation
Page 24
Architecture client serveur – Exposé : Langage SQL
La différence est que leur exécution est déclenchée automatiquement par des événements
liés à des actions sur la base. Les événements déclencheurs peuvent être les commandes
LMD insert, update, delete ou les commandes LDD create, alter, drop.
Une table peut comporter plusieurs déclencheurs d'un type donné, à condition que
chacun possède un nom différent. Cependant, un déclencheur donné ne peut être assigné
qu'à une seule et unique table tout en s'appliquant à la fois, à l'insertion, la mise à jour et la
suppression d'enregistrements sur la table en question.
Une table ne peut posséder qu'un seul déclencheur INSTEAD OF d'un type donné.
Les déclencheurs se produisent soit après (AFTER), soit avant (BEFORE) soit à la
place (INSTEAD OF) d'une action DML.
Un déclencheur sur UPDATE s'exécute à chaque opération de mise à jour lancée par
l'utilisateur ou par un programme. Lors d'une mise à jour, l'ancien enregistrement est
supprimé et inséré dans la table temporaire deleted, tandis que le nouveau est inséré à
la fois dans la table cible et dans la table inserted.
Page 25
Architecture client serveur – Exposé : Langage SQL
ON nom_table
FOR INSERT, UPDATE, DELETE
AS instruction_SQL...
Tous les déclencheurs (ALL) ou certains peuvent être activés (ENABLE) ou désactivés
(DISABLE) au moyen de l'instruction ALTER TABLE.
Exemple
CREATE TABLE tbl_produit ( nom VARCHAR(20), identificateur INTEGER )
GO
INSERT tbl_produit
SELECT 'dentifrice', 1 UNION
SELECT 'savon', 2 UNION
SELECT 'savon', 0 UNION
Page 26
Architecture client serveur – Exposé : Langage SQL
Cet exemple met en exergue le processus permettant de faire appel à différents types de
déclencheurs au sein d'une table. Le premier déclencheur FOR DELETE s'exécute lors
d'une suppression en sélectionnant les lignes supprimées à partir de la table temporaire
deleted. Le second Trigger se déclenche et exécute ses propres instructions à la place de la
commande de déclenchement DELETE afin d'effectuer une comparaison entre les noms de
produits sur les deux tables tbl_produit et deleted pour ensuite supprimer les
enregistrements possédant un identificateur égal à zéro.
Page 27
Architecture client serveur – Exposé : Langage SQL
OPEN nom_curseur[(liste_arguments...)];
Suite à la fin de son utilisation, le curseur peut être fermé afin de ne plus consommer de
ressources. Il est également possible de désallouer le curseur.
CLOSE nom_curseur;
Exemples
-- Déclaration du curseur
DECLARE mycursor CURSOR LOCAL
FOR
Page 28
Architecture client serveur – Exposé : Langage SQL
IV.8 PL/SQL
PL/SQL (Procedural Language / Structured Query Language) est un langage procédural
propriétaire créé par Oracle et utilisé dans le cadre de bases de données relationnelles. Il
permet de combiner des requêtes SQL et des instructions procédurales (boucles,
conditions...), dans le but de créer des traitements complexes destinés à être stockés sur le
serveur de base de données (objets serveur), comme par exemple des procédures stockées
ou des déclencheurs.
Les dernières évolutions proposées par Oracle reposent sur un moteur permettant de créer
et gérer des objets contenant des méthodes et des propriétés.
La structure de base d’un programme PL/SQL est celle de bloc (possiblement imbriqué). Il
a généralement la forme suivante:
DECLARE
/* section de déclaration */
BEGIN
/* corps du bloc de programme
Il s’agit de la seule zone dont la présence est obligatoire */
EXCEPTION
Page 29
Architecture client serveur – Exposé : Langage SQL
IF <condition> THEN
commandes;
[ ELSE IF <condition> THEN
commandes;]
[ ELSE
commandes; ]
END IF;
Exemple
IF nomEmploye=’TOTO’ THEN
salaire:=salaire*2;
ELSE IF salaire>10000 THEN
salaire:=salaire/2;
ELSE
salaire:=salaire*3;
END IF;
commandes;
END LOOP
Toutes ces structures de contrôles peuvent évidemment être imbriquées les unes dans les
autres.
Page 31
Architecture client serveur – Exposé : Langage SQL
PL/SQL permet de définir dans une zone particulière (de gestion d’exception), l’attitude
que le programme doit avoir lorsque certaines erreurs définies ou prédéfinies se produisent.
Un certain nombre d’exceptions sont prédéfinies sous Oracle. Citons, pour les plus
fréquentes : NO DATA FOUND (devient vrai dès qu’une requête renvoie un résultat vide),
TOO MANY ROWS (requête renvoie plus de lignes qu’escompté), CURSOR ALREADY
OPEN (curseur déjà ouvert), INVALID CURSOR (curseur invalide)...
L’utilisateur peut définir ses propres exceptions. Dans ce cas, il doit définir celles ci dans
la zone de déclaration.
Exemple :
excpt1 EXCEPTION
Puis, cette exception est levée quelque part dans le programme (après un test non
concluant, par exemple), par l’instruction :
RAISE excpt1
Enfin, dans la zone d’exception un traitement est affecté à chaque exception possible
(définie ou prédéfinie) :
EXCEPTION
WHEN <exception1> [OR <exception2> OR ...] THEN <instructions>
WHEN <exception3> [OR <exception2> OR ...] THEN <instructions>
WHEN OTHERS THEN <instructions>
END;
Evidemment, un seul traitement d’exception peut se produire avant la sortie du bloc.
IV.8.4 Affichage
PL/SQL n’est pas un langage avec des fonctionnalités d’entrées sorties évoluées (ce n’est
pas son but). Toutefois, on peut imprimer des messages et des valeurs de variables de
plusieurs manières différentes. Le plus pratique est de faire appel à un package prédéfini :
DBMS output.
Page 32
Architecture client serveur – Exposé : Langage SQL
SET SERVEROUTPUT ON
Si on suppose que nom est une variable dont la valeur est ”toto”, l’instruction affichera :
Au revoir toto à bientôt.
Page 33
Architecture client serveur – Exposé : Langage SQL
Légende :
O : Oui
N : Non
X : Existe mais syntaxe hors norme
! : Même nom mais fonction différente
- : implémentation partielle
Norme SQL
Fonction Description Paradox Access MySQL PostGreSQL Oracle Interbase
SQL Server
AVG Moyenne O O O O O O O O
COUNT Nombre O O X O O O O O
MAX Maximum O O O O O O O O
MIN Minimum O O O O O O O O
SUM Total O O O O O O O O
EVERY Tous (booléen) O N N N N N N N
ANY / SOME Au moins un (booléen) O N N N N N N N
a. Agrégation statistique
b. Fonctions "système"
Norme PostGre SQL
Fonction Description Paradox Access MySQL Oracle Interbase
SQL SQL Server
CURRENT_DATE Date courante O N N O O N N O
CURRENT_TIME Heure courante O N N O O N N O
CURRENT_USER Utilisateur courant O N N N O O N N
SESSION_USER Utilisateur autorisé O N N X O O N N
SYSTEM_USER Utilisateur système O N N X O O N N
Nom de la bases de données
DATABASE N N N O N O O N
courante
SYSDATE Date et/ou heure courante N N N O N N O N
USER Utilisateur courant N N N O N O O O
VERSION Version du SGBDR N N N O O N N N
c. Fonctions générales
Page 34
Architecture client serveur – Exposé : Langage SQL
Norme SQL
Fonction Description Paradox Access MySQL PostGreSQL Oracle Interbase
SQL Server
OCTET_LENGTH Longueur en octet O N N O O N O N
DATALENGTH Longueur N N N N N O N N
Fonction
DECODE N N N N N N O N
conditionnelle
LENGTH Longueur N N O O O O O N
NVL Valeur non NULL N N N N N N O N
Conversion de
TO_CHAR N N N N N N O N
données en chaîne
TO_DATE Conversion en date N N N N O N O N
Conversion en
TO_NUMBER N N N N N N O N
nombre
Page 35
Architecture client serveur – Exposé : Langage SQL
f. Fonctions numériques
Norme PostGre SQL
Fonction Description Paradox Access MySQL Oracle Interbase
SQL SQL Server
% Modulo N N N O O O N N
Opérateurs et
+-*/() O O O O O O O O
parenthésage
ABS Valeur absolue N N O O O O O N
Conversion de caractère
ASCII N N O O O O O N
en code ASCII
EXP Exponentielle N N O O O O O N
LN Logarithme népérien N N N N N N O N
Logarithme en base n
LOG(n,m) N N N N O N O N
de m
LOG10 Logarithme décimal N N N O N O O N
MOD Modulo N N O O O O O N
POWER Elévation à la puissance N N O O N O O N
ROUND Arrondi N N O O O O N N
SQRT Racine carrée N N O O O O N N
g. Fonctions temporelles
Norme SQL
Fonction Description Paradox Access MySQL PostGreSQL Oracle Interbase
SQL Server
AGE Age N N N N O N N N
Ajout d'intervalle à
DATE_ADD N N N O N N N N
une date
DATE_FORMAT Formatage de date N N N O N N N N
DAY Jour d'une date N N N N N O N N
DAYNAME Nom du jour N N O O N O N N
HOUR Extraction de l'heure N N O O N O N N
LAST_DAY Dernier jour du mois N N N N N N O N
MINUTE N N O O N O N N
MONTH Mois d'une date N N O O N O O N
Prochain premier jour
NEXT_DAY N N N N N N O N
de la semaine
SECOND Extrait les secondes N N O O N O N N
WEEK Numéro de la semaine N N O O N O O N
YEAR Année d'une date N N O O N O O N
Page 36
Architecture client serveur – Exposé : Langage SQL
Page 37
Architecture client serveur – Exposé : Langage SQL
k. Fonctions spéciales
Norme SQL
Fonction Description Paradox Access MySQL PostGreSQL Oracle Firebird
SQL Server
TABLE SAMPLE Echantillon de données O N N N N O O N
TRUNCATE Vidage de table O N N N N O O O
Limitation des lignes
OFFSET / FETCH O N N N N N N N
retournées
Nombre de ligne
LIMIT/TOP N N N LIMIT LIMIT TOP N ROWS
retournée
"Row Id" Identifiant de ligne N N N _rowid oid N rowid ?
l. Sous requêtes
Norme SQL
Fonction Paradox Access MySQL PostGreSQL Oracle Firebird
SQL Server
Imbriquées O O O N O O O O
Dans la clause SELECT O X O N O O O O
Dans la clause FROM O N N N O O O N
Dans la clause WHERE O O O N O O O O
Page 38
Architecture client serveur – Exposé : Langage SQL
Page 39
Architecture client serveur – Exposé : Langage SQL
Conclusion
SQL est un langage déclaratif régi par les normes qui sont diversement respectées par les
éditeurs des SGBDR. L’évolution de SQL permet aujourd’hui de manipuler aussi des
données relatives au multimédia et d’intégrer des données XML.
Le succès que connaissent les grands éditeurs de SGBDR a plusieurs origines et repose
notamment sur SQL.
SQL peut s’interfacer avec des langages de troisième génération comme C, Ada ou
Cobol, mais aussi avec des langages plus évolués comme C ++, Java, Delphi, C#, etc.
Les procédures stockées offrent des gros avantages pour les applications client/serveur,
surtout au niveau des performances :
- le trafic sur le réseau est réduit car les clients SQL ont seulement à envoyer
l'identification de la procédure et ses paramètres au serveur sur lequel elle est stockée.
- les procédures sont précompilées une seule fois quand elles sont enregistrées.
L'optimisation a lieu à ce moment et leurs exécutions ultérieures n'ont plus à passer par
cette étape et sont donc plus rapides. De plus les erreurs sont repérées dès la compilation et
pas à l'exécution.
Le principal inconvénient des procédures stockées est qu'elles impliquent une dépendance
forte vis-à-vis du SGBD car chaque SGBD a sa propre syntaxe et son propre langage de
programmation.
Ces différences font qu'un code source écrit sans précaution pour un SGBD donné ne
fonctionnera pas forcément avec un autre SGBD.
Page 40
Architecture client serveur – Exposé : Langage SQL
Références
Bibliographie
Pages web
http://sql.developpez.com/
http://www2.laltruiste.com/document.php?
url=http://www2.laltruiste.com/courssql/sommaire.html
http://fr.wikipedia.org/wiki/Structured_Query_Language
http://www.asp-magazine.com/article-110.html
Page 41