L'instruction ALTER PROCEDURE permet de modifier une procédure stockée existante. Le type et l'ampleur des changements possibles varient considérablement selon l'éditeur.

Dans SQL Server, cette instruction modifie une procédure créée précédemment (avec l'instruction CREATE PROCEDURE ), mais elle ne change pas les permissions et n'affecte pas les procédures stockées ou les triggers qui en dépendent.

Dans Oracle, cette commande se contente de recompiler une procédure PL/SQL stockée. Elle ne permet pas de modifier le code. Vous pouvez utiliser la commande Oracle CREATE OR REPLACE PROCEDURE pour obtenir une fonctionnalité identique.

Comme il est expliqué sous CREATE PROCEDURE, la méthode d'accès aux données SQL LANGUAGE, PARAMETER STYLE (par exemple: NO SQL, CONTAINS SQL, etc.), le comportement en cas de clause nulle (par exemple: CALL ON NULL INPUT), DYNAMIC RESULT SET, et le nom de la procédure NAME peuvent tous être modifiés.

La commande ALTER PROCEDURE peut aussi être utilisée pour modifier le nombre ou le type des paramètres d'entrée.

Dans SQL Server, cette commande permet de modifier tous les paramètres d'une procédure stockée déjà créée. Il s'agit en fait d'un raccourci qui évite d'avoir à émettre une instruction DROP PROCEDURE suivie d'une nouvelle instruction CREATE PROCEDURE. Il n'est pas nécessaire de ré-établir les permissions vers la procédure stockée. Pour une explication détaillée de la syntaxe, reportez-vous à la commande CREATE PROCEDURE. Cette commande peut être exécutée dans SQL Server par le propriétaire de la procédure stockée ou par un utilisateur dont le rôle fixe est soit db_owner, soit ddl_admin.

Dans Oracle, le nom de la procédure ou du paquet à compiler doit être fourni. Le mot-clé COMPILE est nécessaire. L'option COMPILE [DEBUG] régénère les informations PL/SQL. Cette commande ne peut être exécutée que par le propriétaire de la procédure stockée ou par les utilisateurs disposant de privilèges qui leur permettent d'exécuter la commande ALTER ANY PROCEDURE.

Cet exemple dans Microsoft SQL Server crée une procédure appelée get_next_br, qui génère une chaîne de sortie CHAR(22) unique. Ensuite, lorsque cette procédure doit être modifiée pour récupérer une valeur de sortie INT unique, ALTER PROCEDURE est utilisé pour la redéfinir:

L'instruction ALTER TABLE permet de modifier une table existante sans l'effacer ni modifier les permissions associées. De ce fait, des changements mineurs peuvent être effectués facilement sur une table existante.

Oracle et Microsoft SQL Server reconnaissent tous les deux cette commande avec un certain nombre de variations adaptées à leurs différentes méthodes d'affectation physique des fichiers.

L'instruction SQL99 ALTER TABLE permet d'apporter de nombreuses modifications utiles à une table. C'est une commande polyvalente qui permet aux utilisateurs d'ajouter une contrainte de colonne ( ADD COLUMN) de table, d'ajouter ou d'éliminer un DEFAULT, d'ajouter ou d'éliminer un SCOPE sur des colonnes qui font référence à un type défini par l'utilisateur et d'éliminer ( DROP) une contrainte de colonne ou de table. DROP RESTRICT avertit l´hôte SGBD d'abandonner la commande s'il se rend compte que d'autres objets de la base de données dépendent de la contrainte de colonne ou de table. DROP CASCADE lui demande d'éliminer tout objet de la base de données qui dépend de la contrainte de colonne ou de table. Pour de plus amples explications sur ces éléments de la commande, consultez l'instruction CREATE TABLE.

L'implémentation d'ALTER TABLEdans Microsoft SQL Server amène de nombreuses fonctionnalités. ALTER COLUMN permet de modifier les propriétés d'une colonne existante comme le type de données, la présence ou non de valeurs nulles, les fonctions d'identité, etc. ADD ajoute une colonne, une colonne calculée ou une contrainte en toute dernière position dans la table (il est pour l'instant impossible d'insérer une colonne ailleurs qu'en dernière position). Le mot COLUMN est indiqué pour des raisons de clarté, mais il n'est pas nécessaire. La nouvelle colonne doit être définie de la même façon qu'avec l'instruction CREATE TABLE, y compris les contraintes, les paramètres par défaut et les fusionnements.

Les clauses WITH CHECK et WITH NOCHECK indiquent à SQL Server si les données de la table doivent être validées en accord avec de nouvelles contraintes ou clés. Lorsque les contraintes ajoutées portent la clause WITH NOCHECK, l'optimiseur de requête l'ignore jusqu´à ce qu'elles soient activées via ALTER TABLE table_name CHECK CONSTRAINT ALL. Les contraintes peuvent être éliminées avec DROP CONSTRAINT (le mot-clé CONSTRAINT n'est cependant pas nécessaire) et activées ou désactivées avec CHECK CONSTRAINT et NOCHECK CONSTRAINT.

De la même façon, un trigger auquel un nom a été attribué peut être activé ou désactivé via les clauses ENABLE TRIGGER et DISABLE TRIGGER. Pour activer ou désactiver simultanément tous les triggers d'une table, il suffit de remplacer le nom de la table par le mot-clé ALL, comme dans l'exemple suivant: ALTER TABLE employee DISABLE TRIGGER ALL.

Reportez-vous à l'instruction CREATE TABLE pour plus de détails sur les attributs de colonne et les contraintes de table autorisés.

L'option IGNORE indique à MySQL d'effacer les lignes dupliquées lors de la définition d'une nouvelle clé unique. Si IGNORE n'est pas précisé, l'opération est abandonnée si un enregistrement dupliqué est identifié sur une clé unique.

L'option FIRST ajoute une colonne en première position dans la table. Il est possible de préciser AFTER column_name pour insérer la nouvelle colonne après le column_name spécifié.

En outre, MySQL permet une certaine flexibilité dans l'instruction ALTER TABLE en permettant aux utilisateurs d'émettre plusieurs clauses ADD, ALTER, DROP et CHANGE dans une même instruction ALTER TABLE. Ne pas oublier toutefois que les clauses CHANGE column_name et DROP INDEX sont des extensions de MySQL que l'on ne retrouve pas dans SQL99. MySQL inclut aussi l'extension Oracle MODIFY column_name. La clause ALTER COLUMN permet de définir ou d'éliminer une valeur par défaut pour une colonne.

Une table peut être renommée via RENAME AS. De même, on peut changer le nom d'une colonne avec CHANGE. Par exemple, le code ci-dessous renomme à la fois une table et une colonne:

Comme MySQL permet de créer des index sur une partie seulement d'une colonne (par exemple, les dix premiers caractères), les commandes CHANGE et MODIFY ne permettent pas de créer des colonnes d'une longueur inférieure à celle de leurs index. Lorsque DROP COLUMN est utilisé, la colonne est éliminée à la fois de la table et des index dans lesquels elle paraît.

DROP PRIMARY KEY n'échoue pas systématiquement en l'absence de clé primaire sur la table. Dans ce cas, MySQL élimine le premier index unique de la table.

MySQL permet de redéfinir le type de données d'une colonne existante sans perdre de données. Les valeurs incluses dans la colonne doivent être compatibles avec le nouveau type de données. Ainsi, une colonne "date" peut être redéfinie pour contenir des données de type "caractères", mais des données de type "caractères" ne peuvent être redéfini en nombre entier. Voici un exemple:

MySQL permet les clauses FOREIGN KEY, CHECK, et REFERENCES, mais elles restent vides. Les commandes émises avec ces clauses sont inopérantes. MySQL les autorise essentiellement pour assurer la compatibilité avec d'autres produits.

L'instruction ALTER TABLE est un parfait exemple de la puissance et du nombre des fonctionnalités qu'Oracle met à la disposition de ses utilisateurs pour contrôler le stockage physique et la manipulation des tables, par exemple: prise en charge des zones de données et des dépassements, et partitionnement des tables pour mieux assurer les périodes d'usage intensifs. Reportez-vous à l'implémentation de CREATE TABLE dans Oracle pour prendre connaissance de la syntaxe spécifique autorisée pour certaines des lignes ci-dessus, comme column_constraint, physical_storage_attributes et nested_table_attributes.

Cette commande peut être utilisée pour ajouter (ADD) de nouvelles colonnes ou contraintes et modifier (MODIFY) ou éliminer (DROP) des colonnes ou contraintes existantes. Toute nouvelle colonne doit être définie comme NULL, à moins que la table n'ait aucune ligne. Le mot-clé MODIFY permet de modifier les caractéristiques d'une table existante. Avec MODIFY CONSTRAINT, vous pouvez éliminer ou modifier les contraintes d'une table, par exemple, activer LOGGING, CACHE ou MONITOR, et décider d'ALLOCATE ou DEALLOCATE les zones de stockage. Les mots-clé ENABLE et DISABLE sont utilisés pour activer ou désactiver les contraintes d'une table.

L'implémentation d'ALTER TABLE dans Oracle est très complexe. Reportez-vous à l'instruction CREATE TABLE pour une explication détaillée des sous-clauses communes aux deux commandes.

Par exemple, le code ci-dessous ajoute simultanément une colonne et une nouvelle contrainte unique à une table dans Oracle:

Quand une contrainte de clé étrangère est ajoutée à une table, le SGBD vérifie que toutes les données existantes de la table la respectent. Si ce n'est pas le cas, la commande ALTER TABLE échoue.

Toute application qui inclut le mot-clé SELECT * renvoie les nouvelles colonnes, même si ce n'était pas prévu. En revanche, les objets pré-compilés, comme les procédures stockées, peuvent ne renvoyer aucune nouvelle colonne.

Oracle permet également d'effectuer simultanément plusieurs actions (ADD, MODIFY, etc.) sur un certain nombre de colonnes, en mettant l'action entre parenthèses. Par exemple, la commande ci-dessous ajoute plusieurs colonnes à une table avec cette seule instruction:

L'implémentation de ALTER TABLE dans PostgreSQL permet d'ajouter des colonnes à l'aide du mot-clé ADD . Il est possible d'attribuer de nouvelles valeurs par défaut aux colonnes existantes avec ALTER COLUMN... SET DEFAULT, tandis qu'ALTER COLUMN... DROP DEFAULT permet d'éliminer la valeur par défaut d'une colonne. En outre, de nouvelles valeurs par défaut peuvent être ajoutées à des colonnes avec la clause ALTER, mais elles ne s'appliqueront qu'aux lignes insérées. RENAME permet de renommer les colonnes et tables existantes.

L'instruction ALTER TRIGGER modifie la définition d'un trigger existant sans qu'il soit nécessaire de modifier les permissions ou les dépendances.

Il n'existe pour l'instant pas de norme SQL99 pour cette commande.

Microsoft SQL Server permet de spécifier FOR | AFTER | INSTEAD OF { [DELETE] [,] [UPDATE] [,][INSERT] } | { [INSERT] [,] [UPDATE] } pour décrire le trigger de modification des données affecté par la commande. Toutes les permutations sont possibles à condition qu'au moins un de ces éléments soit inclus. Il suffit de séparer les options supplémentaires par des virgules. Les options FOR et AFTER sont essentiellement identiques et indiquent que le code du trigger doit s'exécuter une fois la manipulation des données terminée. On peut également utiliser l'expression INSTEAD OF pour indiquer à SQL Server de remplacer l'opération par le code du trigger.

L'expression WITH APPEND demande à SQL Server d'ajouter un trigger du type indiqué à la table de base. Cette option n'est autorisée que sur les triggers FOR. L'expression NOT FOR REPLICATION indique à SQL Server de ne pas exécuter le trigger lorsque l'action est lancée par un nom d'utilisateur dupliqué, comme sqlrepl. La clause IF UPDATE (column) vérifie s'il existe une action INSERT ou UPDATE (mais pas DELETE) sur une colonne donnée, ce qui peut être très utile lorsqu'on procède à des opérations sur les lignes avec un curseur. Les opérateurs {AND | OR} permettent de tester des colonnes supplémentaires dans la même phrase. IF (COLUMNS_UPDATED( )) teste un trigger INSERT ou UPDATE pour voir si les colonnes mentionnées ont été affectées. Les résultats sont délivrés sous la forme d'opérateurs binaires.

Oracle ne permet pas de modifier complètement le code sous-jacent du trigger via cette commande (mais on obtient cette même fonctionnalité avec CREATE OR REPLACE TRIGGER). Dans Oracle, ALTER TRIGGER permet d'activer, de désactiver ou de recompiler un trigger. L'option COMPILE [DEBUG] régénère les informations PL/SQL.

Oracle ne permet l'utilisation de triggers que sur les tables (bien que les triggers INSTEAD OF soient autorisés sur les vues). Microsoft SQL Server permet l'utilisation de triggers sur les tables et sur les vues qui peuvent être mises à jour.

Comme il n'existe pas, pour l'instant, de norme SQL99 pour l'instruction ALTER VIEW , il est important de noter que cette commande se comporte différemment dans chacune des applications majeures qui la proposent. Oracle l'utilise pour recompiler les vues, tandis que dans Microsoft SQL Server, elle permet de modifier une vue sans nécessairement mettre à jour les procédures stockées, triggers ou permissions qui en dépendent.

Il n'existe pour l'instant pas de norme SQL99 pour cette commande.

Comme c'est le cas pour l'instruction CREATE VIEW, ALTER VIEW permet à un programmeur de préciser les alias que la vue utilise pour nommer les colonnes, ainsi que la totalité de l'instruction SELECT qui est le composant central de la vue.

Les autres clauses de l'instruction ALTER VIEW sont décrites sous l'instruction CREATE VIEW.

Microsoft SQL Server ne peut conserver les permissions sur les colonnes que si leurs noms sont maintenus après exécution de la commande. Le mot-clé ENCRYPTION permet de chiffrer les codes de vues au sein de la table système syscomments dans SQL Server. Le mot-clé CHECK OPTION oblige toutes les modifications de données exécutées dans une vue à obéir aux critères du select_statement qui la définissent. Si l'une ou l'autre de ces options figuraient auparavant dans la vue, elles doivent être activées à l'aide de l'instruction ALTER VIEW pour être opérantes.

Dans Oracle, l'instruction ALTER VIEW recompile une vue. Elle est utile pour valider une vue après avoir apporté des changements à une table de base. Si les tables de base changent sans que la vue correspondante soit recompilée, celle-ci est invalide.

Cet exemple tiré de SQL Server crée une vue intitulée california_authors qui contient les noms d'auteurs vivant en Californie, puis se sert de la commande ALTER VIEW pour élargir et remplacer la vue:

L'instruction CALL invoque une procédure stockée.

L'instruction CALL facilite l'invocation d'une procédure stockée. Il suffit de saisir le nom de la procédure et d'inclure entre parenthèses les paramètres qu'elle utilise. Les parenthèses peuvent être vides si la procédure stockée n'a que des paramètres OUT ou n'a pas de paramètres du tout.

Microsoft SQL Server ne prend pas en charge l'instruction CALL. Toutefois, l'instruction EXECUTE. Reportez-vous à la documentation de l'éditeur pour une explication détaillée de cette extension SQL Server.

Oracle permet d'utiliser l'instruction CALL pour invoquer des procédures stockées, des fonctions et des méthodes autonomes, ainsi que des procédures stockées et des fonctions contenues dans un type ou un paquet. Si la procédure ou la fonction réside dans une autre base de données, il suffit de déclarer la base de données (en précisant où l'objet réside) avec une instruction dblink dans l'instruction CALL. dblink doit se référer à un lien de base de données existant.

Si la routine ainsi appelée est une fonction, Oracle exige la clause INTO. Par conséquent, INTO ne peut être utilisée que lorsqu'une fonction est invoquée. La variable qui stockera la valeur renvoyée par la fonction doit être fournie. Enfin, si la fonction est une routine Pro*C/C++ pré-compilée, un indicateur peut aussi être précisé pour retenir la condition de la variable hôte.

Dans cet exemple, une procédure stockée simple est créée, puis invoquée indépendamment:

La fonction CASE assure la fonctionnalité IF-THEN-ELSE au sein d'une instruction SELECT ou UPDATE. Elle évalue une liste de conditions et renvoie l´une des valeurs possibles.

CASE peut être utilisé de deux façons: simple et conditionnelle. Les expressions CASE simples comparent une valeur, input_value, avec une liste d'autres valeurs et renvoient un résultat associé à la première concordance. Les expressions CASE conditionnelles permettent d'analyser plusieurs conditions logiques et renvoient un résultat associé à la première qui soit vraie.

Dans la fonction CASE simple, la valeur input_value est évaluée et comparée à chaque clause WHEN. Le résultat resulting_value est renvoyé pour la première instance où input_value = when_conditionest TRUE. Si aucune when_condition n'est TRUE, alors else_result_value est renvoyée. Si else_result_value n'est pas spécifiée, alors le résultat NULL est renvoyé.

La structure de l'opération conditionnelle logique, plus complexe, est essentiellement identique à celle de l'opération de comparaison simple, sauf que chaque clause WHEN a sa propre opération de comparaison logique.

Quelle que soit la version choisie, on utilise des clauses WHEN multiples, bien qu'une seule clause ELSE soit nécessaire.

Voici une comparaison simple où la fonction CASE modifie l'apparence de la colonne "contrat" pour en faciliter la compréhension:

Voici une fonction conditionnelle CASE plus complexe, intégrée à une instruction SELECT qui montre le cumul des ventes par titre pour l'année en cours:

Cette instruction donne les résultats suivants:

Voici une instruction UPDATE qui applique une remise sur tous les titres. La commande suivante est plus complexe: elle applique une remise de 25 % sur tous les titres ayant trait à la microinformatique, de 5 % sur les titres dont les ventes cumulées dépassent 10 000 exemplaires, et de 10 % sur tous les autres titres.

La requête UPDATE ci-dessous a recours à une expression CASE conditionnelle pour ajuster les prix:

Trois opérations de mise à jour différentes sont donc exécutées simultanément, avec une seule instruction.

La commande CAST convertit explicitement une expression d'un type de données à un autre.

La fonction CAST convertit une expression quelconque, par exemple une valeur ou une variable prises dans une colonne, en un type de données défini. Il est possible de préciser la longueur des données en caractères pour les types qui la reconnaissent (comme CHAR ou VARCHAR).

Il faut savoir que certaines conversions, par exemple la conversion d'une valeur décimale (DECIMAL) à un nombre entier (INTEGER), auront pour résultat d'arrondir le chiffre concerné. En outre, il peut arriver que les conversions aboutissent à des erreurs si le nouveau type de données ne dispose pas de l'espace nécessaire pour afficher la valeur convertie.

Dans cet exemple, la commande récupère le chiffre des ventes cumulées pour l'année en cours sous forme de CHAR et y accole une chaîne en langage clair suivie d'une partie du titre du livre. Elle convertit ytd_sales à CHAR(5), et raccourcit title pour que les résultats soient plus faciles à lire:

On obtient ce qui suit:

La commande CLOSE CURSOR ferme un curseur serveur créé à l'aide d'une instruction DECLARE CURSOR . MySQL ne prend pas en charge les curseurs serveur, mais offre quantité d'options de programmation en C.

cursor_name représente le nom du curseur créé à l'aide de la commande DECLARE CURSOR.

Cet exemple tiré de Microsoft SQL Server ouvre un curseur et extrait toutes les lignes:

Dans Microsoft SQL Server, l'instruction DEALLOCATE libère les ressources et les structures de données mobilisées par le curseur, mais elle n'est utilisée ni par Oracle, ni par PostgreSQL, ni par MySQL.

L'instruction COMMIT TRANSACTION conclut de façon explicite une transaction ouverte, qu'elle ait été ouverte explicitement avec BEGIN, ou implicitement dans le cadre d'une instruction INSERT, UPDATE ou DELETE. Cette commande permet de mettre fin manuellement de façon permanente à une opération de manipulation des données.

Outre le fait de mettre un point final à une série d'opérations de manipulation des données (ou à une opération unique), l'instruction COMMIT a des effets intéressants sur d'autres aspects d'une transaction. Premièrement, elle ferme tous les curseurs associés restés ouverts. Deuxièmement, les données sont effacées de toutes les tables temporaires pour lesquelles ON COMMIT DELETE ROWSa été spécifié. Troisièmement, tous les verrous posés par la transaction sont libérés. Enfin, toutes les contraintes différées sont vérifiées. Si les contraintes différées sont enfreintes, la transaction est annulée.

Il est à noter que, selon la norme SQL99, une transaction est implicitement ouverte lorsque l'une des instructions suivantes est exécutée:

• ALTER
• CLOSE
• COMMIT AND CHAIN (nouveau dans SQL99)
• CREATE
• DELETE
• DROP
• FETCH
• FREE LOCATOR
• GRANT
• HOLD LOCATOR
• INSERT
• OPEN
• RETURN
• REVOKE
• ROLLBACK AND CHAIN (nouveau dans SQL99)
• SELECT
• START TRANSACTION (nouveau dans SQL99)
• UPDATE

SQL99 permet d'utiliser le nouveau mot-clé optionnel AND CHAIN. Aucun de nos éditeurs ne prend en charge cette commande pour l'instant. La nouvelle syntaxe est:

L'option AND CHAIN demande au SGBD de traiter la transaction qui suit comme si elle faisait partie de la précédente. C'est utile pour traiter deux transactions qui représentent des unités de travail séparées, mais qui partage un même environnement (comme le niveau d'isolation des transactions). L'option AND NO CHAIN clôt simplement la transaction unique. D'un point de vue fonctionnel, la commande COMMIT est équivalente à la commande COMMIT WORK AND NO CHAIN.

Microsoft SQL Server permet de valider une transaction spécifique à laquelle un nom a été attribué. La commande COMMIT doit être associée à une commande BEGIN TRAN. La syntaxe de COMMIT TRANSACTION permet aux programmeurs de spécifier une transaction explicite pour fermer ou stocker un nom de transaction dans une variable. Curieusement, SQL Server ne valide toujours que la dernière transaction ouverte, quel que soit le nom de transaction spécifié. COMMIT WORK permet d'omettre le nom de transaction ou la variable contenant un nom de transaction.

Toutefois, cette syntaxe peut porter à confusion en présence de triggers imbriqués, puisqu'elle ferme la transaction la plus à gauche. Dans SQL Server, les transactions sont identifiées de façon numérique par la variable globale @@TRANCOUNT . Les transactions ne sont validées que lorsque @@TRANCOUNT égale 0.

Oracle ne permet pas d'attribuer un nom spécifique à une transaction (mais il autorise les points de sauvegarde); par conséquent, la commande COMMIT sert simplement à valider toutes les opérations de manipulation des données effectuées depuis l'exécution de la dernière instruction COMMIT implicite or explicite. Oracle autorise le mot-clé WORK , mais il est entièrement facultatif.

Dans PostgreSQL, les mots-clé WORK et TRANSACTION sont tous deux facultatifs. Le résultat de la commande est le même, avec ou sans l'un ou l'autre des mots-clé. Lorsque la commande est terminée, toutes les transactions validées ont été sauvegardées et peuvent être vues par les autres utilisateurs.

Si nécessaire, on peut utiliser le symbole de concaténation reconnu par le SGBD pour combiner les données de plusieurs colonnes dans le jeu de résultats SELECT .

Selon la norme ANSI, le symbole de la concaténation est le signe ||, soit une double barre verticale, comme dans l'exemple de code ci-dessus. Ce symbole est pris en charge par Oracle et PostgreSQL.

Dans Microsoft SQL Server, c'est le signe plus (+) qui sert à indiquer la concaténation.

MySQL utilise la fonction CONCAT(string1, numeric1, string2, numeric2 [,...n]) pour opérer la concaténation.

L'instruction CONNECT établit une connexion au SGBD et à une base de données spécifique au sein du SGBD.

Si l'instruction CONNECT est invoquée sans qu'il y ait eu de déconnexion explicite, la session en cours devient inactive et une nouvelle session est ouverte. La période comprise entre l'émission d'une instruction CONNECT et celle d'une instruction DISCONNECT est appelée session. Habituellement, les utilisateurs accomplissent leur travail sur un SGBD au cours d'une session invoquée de façon explicite.

L'outil Oracle SQL*Plus utilise la commande CONNECT d'une façon assez différente, puisqu'il s'en sert pour connecter un utilisateur à un schéma particulier.

L'instruction CONNECT TO DEFAULT donne des résultats variables selon les éditeurs car elle est implémentée de façon différente. Toutefois, selon la norme, cette commande devrait lancer une session sur le serveur par défaut avec l'identifiant d'autorisation par défaut et ouvrir la base de données active.

Contrairement à CONNECT TO DEFAULT, CONNECT TO server_name permet à l'utilisateur de préciser le serveur à utiliser. Ici, la connexion se fait vers le serveur explicitement désigné. En outre, la connexion peut être déclarée en utilisant AS et un nom d'utilisateur spécifique avec USER.

La clause CONNECT permet de se connecter à une base de données avec un nom d'utilisateur spécifique. Il est aussi possible d'établir une connexion avec des privilèges particuliers en utilisant AS SYSOPER ou AS SYSDBA. Si une autre connexion est déjà active, CONNECT valide les transactions ouvertes, ferme la session en cours et en ouvre une nouvelle.

PostgreSQL ne prend pas explicitement en charge la commande CONNECT. Toutefois, il admet l'instruction SPI_CONNECT sous l´Interface de Programmation du Serveur et PG_CONNECT sous l'outil de programmation PG/tcl.

Pour se connecter avec un nom d'utilisateur spécifique, l'utilisateur (ou le programme automatisé) peut émettre la commande suivante:

Si le SGBD exige qu'un nom soit utilisé pour permettre une connexion, on peut se servir de cette syntaxe:

Microsoft SQL Server ne prend en charge CONNECT TO que lorsqu'elle est intégrée dans Embedded SQL (ESQL):

En fait, il n'existe pas d'instruction CREATE DATABASE dans SQL99. Les instructions SQL99 les plus proches de CREATE DATABASE sont CREATE SCHEMA et CREATE CATALOG (CREATE SCHEMA est décrite ci-après). Toutefois, il est presque impossible de travailler sur une base de données SQL sans cette commande. Presque tous les éditeurs de bases de données en proposent une version.

Dans cette syntaxe, database_name est l'identifiant de la base de données en cours de création. Cette commande crée une base de données vierge dotée d'un nom qui lui est propre. Dans la plupart des SGBD, l'utilisateur doit être connecté au compte root, master, ou system database pour procéder à la création d'une base de données. Une fois la nouvelle base de données créée, elle est prête à recevoir des objets de base de données (tables, vues, triggers, etc.), et les tables à accueillir des données.

Dans SQL Server et Oracle, la base de données est instanciée dans une structure de fichiers créée à l'avance. Les fichiers servent d'intermédiaires entre le système de base de données et le système d'exploitation. En conséquence, les variantes SQL Server et Oracle de CREATE DATABASE sont plus élaborées.

La syntaxe dans Microsoft SQL Server ressemble à ce qui suit:

Dans cette implémentation, il est non seulement possible de fournir le nom de la base de données, mais aussi de spécifier l'emplacement où on souhaite qu'elle soit stockée. Oracle et SQL Server utilisent tous les deux files (un espace prédéfini dans la structure du disque) comme dépôt pour les bases de données. Les bases de données peuvent être stockées dans un ou plusieurs fichiers ou groupes de fichiers. SQL Server permet aussi de conserver le journal des transactions dans un emplacement séparé via la clause LOG ON. Grâce à ces fonctions, il est possible de planifier les fichiers de façon à permettre un contrôle optimal des E-S sur disque.

Les clauses FOR LOAD précisent que dès sa création, la base de données sera chargée à partir d'une copie de sauvegarde, ce qui permet d'accélérer le processus de création initial. La clause FOR ATTACH indique à SQL Server que la base de données est rattachée à partir d'une structure de fichiers de système d'exploitation existante, soit un DVD-ROM, un CD-ROM ou un disque dur portable.

Dans MySQL, CREATE DATABASE revient essentiellement à créer un nouveau répertoire qui contient les objets de la base de données. Ainsi, avec les systèmes de ces éditeurs, il n'est guère plus difficile de créer une base de données que de créer un répertoire de système de fichiers. La base de données est créée sous forme de répertoire dans le répertoire principal de l'éditeur, et les nouveaux objets créés au sein de la base de données sont placés dans ce même répertoire. PostgreSQL offre la même fonctionalité, mais permet en plus de spécifier l'emplacement de la base de données avec l'option WITH LOCATION:

Par exemple, pour créer la base de données sales_revenue dans le répertoire /home/teddy/private_db:

Dans Oracle, CREATE DATABASE est une commande très puissante et devrait être réservée aux administrateurs de bases de données expérimentés. Les novices devraient être conscients que l'utilisation de cette commande pose un risque de destruction de la base de données existante.

Comme Microsoft SQL Server, Oracle permet de contrôler de nombreux aspects des structures de fichiers de la base de données, bien au-delà de l'attribution d'un nom ou de la désignation du chemin d'accès de ses fichiers. De même, le fichier INIT.ORA, qui précise le nom et toute une série d'autres options au moment de la création et du démarrage de la base de données, est une particularité de l'environnement Oracle. Le fichier INIT.ORA, qui indique les fichiers de contrôle, doit obligatoirement être utilisé. Dans le cas contraire, il serait impossible de lancer la base de données.

Lorsque l'option the file1 [,...n] est disponible, le nom et la taille du fichier peuvent être indiqués en octets, kilooctets ou mégaoctets selon le format suivant:

Les options [K | M] multiplient respectivement la taille du fichier en octets par 1024 et 1048576. Tandis que l'option REUSE peut soit créer un nouveau fichier, soit, le cas échéant, réutiliser un fichier existant, CONTROLFILE REUSE efface les fichiers de contrôle. De la même façon, LOGFILE... REUSE efface les fichiers journaux.

Les groupes de fichiers journaux sont habituellement affichés entre parenthèses. Les parenthèses ne sont pas nécessaires lorsqu'on crée un groupe qui ne compte qu'un seul membre, mais elles sont rarement omises. Voici un exemple de liste de fichiers journaux entre parenthèses:

En outre, les options et sous-options LOGFILE et DATAFILE permettent un contrôle précis de la taille et des modes de croissance des fichiers de reprise et des fichiers de données. MAXLOGFILES et MAXDATAFILES définissent respectivement le nombre maximal absolu de fichiers de reprise et de fichiers de données. Quand AUTOEXTEND est activé, le fichier de données grossit par incréments de NEXT jusqu´à atteindre MAXSIZE, à moins qu'il ne soit paramétré sur UNLIMITED. MAXLOGMEMBERS contrôle le nombre maximum de copies d'un groupe de fichiers de reprise. MAXLOGHISTORY, qui est utilisé dans Oracle Parallel Server, contrôle le nombre maximum de fichiers de reprise archivés de telle sorte que la quantité d'espace inscrite dans le fichier de contrôle est correcte.

Le paramètre MAXINSTANCES fixe le nombre maximum d'instances qui peuvent être introduites dans la base de données en cours de création. ARCHIVELOG | NOARCHIVELOG sont des options contradictoires qui définissent le fonctionnement des fichiers de reprise. ARCHIVELOG sauvegarde les données vers un fichier d'archivage supplémentaire, assurant la possibilité de rétablir le support. Ces options offrent toutes les deux une faculté de récupération, mais NOARCHIVELOG (le réglage par défaut) ne permet en général pas de rétablir le support. CHARACTER SET, qui dépend du système d'exploitation, contrôle la langue et le jeu de caractères dans lesquels les données sont stockées.

L'instruction CREATE FUNCTION crée une fonction définie par l'utilisateur qui part des arguments saisis et renvoie une valeur unique, de la même façon que CAST( ). Comme toute autre fonction système, une fonction utilisateur peut être invoquée dans une requête.

Reportez-vous au chapitre 4 pour une description exhaustive des fonctions SQL et de leur implémentation par les différents éditeurs.

L'instruction CREATE FUNCTION permet aux programmeurs de base de données de créer des fonctions qu'ils définissent eux-mêmes, les fonctions utilisateur. Ces fonctions, une fois créées, peuvent être invoquées dans des requêtes et des opérations de manipulation des données comme INSERT, UPDATE et la clause WHERE des instructions DELETE. Bien que la syntaxe de base de l'instruction ait été montrée plus haut, cette commande a été implémentée de tant de façons différentes par les différents éditeurs que les syntaxes sont reprises plus bas dans cette section.

La norme SQL99 pour l'instruction CREATE FUNCTION comprend un composant principal et un composant plus élaboré, moins souvent utilisé. Dans la plupart des fonctions utilisateur, l'utilisateur définit le nom de la fonction, les paramètres d'entrée souhaités, et la valeur qu'elle renvoie. Ce sont les usages de base de cette commande.

Cependant, la norme SQL99 permet d'en faire beaucoup plus. LANGUAGE spécifie le langage de la fonction (par exemple: PostgreSQL). PARAMETER STYLE permet de déclarer un style de paramètre autre que le style SQL typique via le mot-clé GENERAL (SQL demeure le langage par défaut). SPECIFIC est utilisé pour préciser davantage le nom de la fonction dans un type défini par l'utilisateur. Les clauses DETERMINISTIC ou NOT DETERMINISTIC indiquent au SGBD hôte si la fonction doit toujours renvoyer le même résultat pour les mêmes paramètres d'entrée (elle est déterministique) ou non. Seules les fonctions déterministiques peuvent être utilisées dans les contraintes.

La clause d'accès aux données SQL indique au SGBD hôte si la fonction contient du code SQL ou non par CONTAINS SQL ou NO SQL, si elle utilise les instructions SELECT ou FETCH par READS SQL DATA, ou enfin si elle comporte une instruction de modification des données par MODIFIES SQL DATA. CONTAINS SQL est la valeur par défaut.

Pour les langages hôtes qui n'acceptent pas les nuls, il est possible de déclarer RETURNS NULL ON NULL INPUT pour demander à la fonction de renvoyer immédiatement un nul en échange d'un nul. En revanche, CALL ON NULL INPUT (la valeur par défaut) traite le paramètre nul normalement, et peut renvoyer des résultats inconnus.

La clause STATIC DISPATCH est utilisée pour les fonctions non-SQL dont certains paramètres utilisent les types utilisateur, ou ARRAYS.

Les fonctions SQL Server peuvent renvoyer plusieurs valeurs via le type de données TABLE. Le type de données TABLE est considéré comme inline s'il n'est pas accompagné d'une liste de colonnes et s'il est défini à l'aide d'une seule instruction SELECT. Si la clause RETURN livre plusieurs valeurs via le type de données TABLE, et si la TABLE a défini des colonnes avec leur type de données, cette fonction est une fonction multi-instructions à valeur table.

SQL Server exige qu'un ou plusieurs paramètres fournis par l'utilisateur soient déclarés pour une fonction utilisateur donnée. Tous les types de données SQL Server sont reconnus comme des paramètres, sauf timestamp. Les valeurs renvoyées par la fonction peuvent appartenir à n'importe quel type de données sauf timestamp, text, ntext ou image. Si une valeur de table inline est requise, l'option TABLE sans liste de colonnes peut être utilisée.

Les fonctions utilisateur de Microsoft SQL Server, comme de nombreux autres objets de base de données dans SQL Server, peuvent être créées avec les options ENCRYPTION ou SCHEMABINDING. L'option ENCRYPTION indique à SQL Server de chiffrer la table à colonnes du système où le texte de la fonction est stocké, et ainsi d'empêcher une révision intempestive du code de la fonction. L'option SCHEMABINDING précise que la fonction est liée à un objet de base de données spécifique, tel qu'une table ou une vue. Cet objet de base de données ne peut être ni modifié, ni abandonné aussi longtemps que la fonction existe (ou qu'elle conserve l'option SCHEMABINDING).

Le corps du code Transact-SQL consiste soit en une seule instruction SELECT pour une fonction inline, selon le format RETURN (SELECT...), soit en une série d'instructions Transact-SQL pour une opération multi-instructions. Le corps du Transact-SQL contenu dans un bloc BEGIN... END ne peut pas modifier les données de façon permanente, ni causer d'effets secondaires durables. La dernière instruction du bloc doit être un RETURN inconditionnel qui renvoie une valeur de type de données ou une valeur TABLE unique.

Le bloc Transact-SQL ne peut contenir de variables globales renvoyant des valeurs changeantes, comme @@CONNECTIONS ou GETDATE, mais il peut contenir des variables renvoyant des valeurs uniques toujours identiques, comme @@SERVERNAME. Il existe un certain nombre d'autres restrictions dues au fait le code ne peut modifier les données de façon permanente, ni causer d'effets secondaires durables. Par exemple, les instructions INSERT, UPDATE et DELETE ne peuvent modifier que des variables TABLE locales de la fonction.

L'exemple suivant montre une fonction scalaire qui renvoie une valeur unique:

Comme n'importe quelle autre fonction, cette fonction utilisateur peut être utilisée dans une requête ou pour toute autre opération. Par exemple, on peut déterminer le nom et le volume métrique de tous les projets de construction dépassant 300 000 en volume métrique:

Les fonctions utilisateur qui renvoient une valeur de table sont souvent sélectionnées comme valeurs d'un jeu de résultats ou utilisées dans la clause FROM d'une instruction SELECT, tout comme une table ordinaire. Dans une clause FROM, une fonction alias de table peut être désignée exactement comme une table ordinaire. Par exemple:

Dans MySQL, CREATE FUNCTION rassemble des fonctions utilisateur, comme SUM( ) et COUNT( ), via l'option AGGREGATE. Le type de valeur renvoyée peut être soit STRING pour les données de type caractère, REAL pour les nombres à virgule flottante ou INTEGER pour les nombres entiers.

L'implémentation de CREATE FUNCTION dans MySQL diffère considérablement de celle des autres éditeurs puisque le code procédural doit être en C/C++ et s'exécuter sous un système d'exploitation qui supporte le chargement dynamique. Le programme C/C++ est nommé dans l'option shared_program_library_name. La fonction peut être compilée soit directement dans le serveur MySQL, ce qui la rend disponible de façon permanente, soit comme un programme appelé dynamiquement. La fonction utilisateur étant rédigée sous la forme d'un programme en C/C++, sa description détaillée dépasse le cadre de cet ouvrage.

Dans Oracle, les fonctions utilisateur et les procédures stockées présentent une composition et une structure tout à fait similaires. La différence essentielle est que les procédures stockées ne peuvent pas renvoyer de valeurs au processus d'invocation, tandis que les fonctions peuvent renvoyer une valeur unique.

Dans une fonction utilisateur Oracle, les arguments et paramètres spécifiés incluent IN, OUT et IN OUT. Le qualificateur IN est fourni lorsque la fonction est invoquée et il envoie une valeur à la fonction, tandis que l'argument OUT renvoie une valeur au processus d'invocation. En d'autres termes, le qualificateur IN est fourni par l'utilisateur ou le processus qui appelle la fonction, tandis que l'argument OUT est renvoyé par la fonction. Les arguments IN OUT exécutent aussi bien les fonctionnalités de IN que de OUT. Le mot-clé NOCOPY est utile pour accélérer la performance quand un argument OUT ou IN OUT est très volumineux, comme c'est le cas pour les données de type varray ou enregistrement.

Le mot-clé RETURN spécifie le type de données de la valeur renvoyée par la fonction. Le mot-clé DETERMINISTIC sert à accélérer le traitement par les fonctions qui ont été explicitement déclarées déterministiques. La valeur de retour stockée peut provenir d'une vue matérialisée, d'un appel simultané de la même fonction ou d'un index basé sur la fonction. Il est aussi possible d'obliger la fonction à s'exécuter soit dans le contexte de permission de l'utilisateur actif avec l'expression AUTHID CURRENT_USER, soit dans celui du propriétaire de la fonction avec l'expression AUTHID DEFINER.

Par exemple, les profits engendrés par un projet de construction peuvent être determinés en envoyant le nom du projet avec cette fonction:

Dans cet exemple, la fonction utilisateur accepte le nom de projet comme argument. Ensuite, elle traite les revenus du projet, de manière invisible, en soustrayant les coûts de départ du paiement final, et en y ajoutant tous les autres paiements reçus. La ligne RETURN(proj_rev); renvoie le montant au processus d'invocation.

L'implémentation de la commande CREATE FUNCTION par PostgreSQL compte parmi les plus souples qui soient. Comme pour les autres implémentations, les parameters sont invoqués et renvoient une valeur de type de données. PostgreSQL permet aussi la surcharge de la fonction, c'est-à-dire que plusieurs fonctions peuvent porter le même nom, à conditions qu'elles acceptent des paramètres d'entrée distincts.

L'attribut de type de données WITH ISCACHABLE optimise la performance de PostgreSQL en indiquant que la fonction renvoie toujours les mêmes valeurs pour les mêmes paramètres. Cette configuration permet ensuite à l'optimiseur de pré-évaluer l'appel de la fonction.

La definition peut consister en une chaîne qui définit la fonction (selon le langage dans lequel la fonction est écrite), comme un nom de fonction interne, le chemin d'accès et le nom d'un fichier objet, une requête SQL ou le texte d'un langage procédural. La définition peut aussi être un object file et un link symbol vers une fonction en C.

Voici un exemple de fonction SQL simple dans PostgreSQL:

Dans PostgreSQL, CREATE FUNCTION remplace CREATE PROCEDUREet sert également à définir des actions pour CREATE TRIGGER.

Le mot-clé LANGUAGE permet à la fonction PostgreSQL d'appeler un programme extérieur. Ces programmes étant compilés dans d'autres langages, ils dépassent le cadre de cet ouvrage. Toutefois, il convient d'utiliser la clause LANGUAGE `sql' pour écrire des fonctions utilisateur en SQL.

Les index sont des objets particuliers créés à partir des tables et qui accélèrent de nombreuses opérations de manipulation des données, comme les instructions SELECT, UPDATE et DELETE. Lorsqu'un index est créé, l'emplacement et l'étendue des valeurs de la colonne indexée (appelés statistiques) sont déterminés. La sélectivité d'une clause WHERE donnée est habituellement fondée sur la qualité des index placés sur la table.

La commande CREATE INDEX varie beaucoup d'un éditeur à l'autre. L'une des raisons en est que certains éditeurs de SGBD l'utilisent pour déterminer la façon dont les données d'une table sont physiquement triées et rangées sur le disque.

Tous les principaux éditeurs reconnaissent les index composés, aussi nommés index concaténés. Ces index sont utilisés lorsqu'il est préférable d'effectuer une recherche sur deux colonnes (ou plus), en les traitant comme une seule entité (par exemple, les colonnes «  nom » et «  prénom »).

Microsoft SQL Server offre des options d'importance. Par exemple, on peut créer des index soit ascendants, soit descendants sur les tables. On peut également créer des index sur les vues et les colonnes calculées (comme UPPER(book_name) ou ((qty * amt) / royalty) ). SQL Server permet aussi de spécifier plusieurs arguments optionnels: UNIQUE, CLUSTERED, ou NONCLUSTERED (défaut). Les index uniques interdisent la saisie de valeurs identiques dans les colonnes indexées. Toute tentative d'insertion ou de mise à jour qui dupliquerait une valeur déjà présente dans l'index causerait une erreur. Les index clusterisés précisent l'ordre de tri physique des données sur le disque. Les index non clusterisés créent un ordre logique qui est utilisé pour accélérer les opérations de manipulation des données.

SQL Server permet des syntaxes additionnelles:

1. PAD_INDEX précise que tel espace devrait rester vierge sur chaque page de l'index, en fonction de la valeur de FILLFACTOR.
2. FILLFACTOR est une valeur exprimée en pourcentage (de 1 à 100) qui indique à SQL Server le taux de remplissage à respecter pour chaque page de 8 Ko au moment de la création de l'index. C'est utile pour éviter d'avoir à trop diviser les pages à mesure qu'elles se remplissent, et donc réduire les opérations de disque à forte proportion d'E/S. La création d'un index clusterisé avec un facteur de remplissage explicite peut augmenter la taille de l'index et, dans certaines circonstances, en accélérer le traitement.
3. IGNORE_DUP_KEY détermine l'action entreprise lorsqu'un enregistrement d'un index unique est dupliqué suite à une opération d'insertion ou de mise à jour. Si l'option est configurée, seule la ligne dupliquée est exclue de l'opération. Sinon, alors tous les enregistrements sur lesquels porte l'opération sont annulés (même s'ils ne sont pas dupliqués).
4. DROP_EXISTING est une option utile puisqu'elle permet d'indiquer à SQL Server d'abandonner tous les index existants et de recréer l'index spécifié.
5. STATISTICS_NORECOMPUTE empêche SQL Server de recalculer les statistiques d'index. Ceci peut accélérer l'opération CREATE INDEX, mais tend à réduire l'utilité de l'index.
6. ON filegroup crée un index sur un groupe de fichiers existant. Il devient alors possible de placer les index sur un disque dur ou un périphérique RAID spécifique.

La création d'un index demande habituellement 1,2 à 1,5 fois plus d' espace que la table n'en occupe normalement. La majorité de cet espace supplémentaire est libérée une fois l'index créé.

MySQL suit la norme ANSI de base pour l'instruction CREATE INDEX, y compris la faculté de générer un index sur plusieurs colonnes. Un index peut être défini comme UNIQUE, ce qui l'oblige à n'accepter que des valeurs uniques. Toute tentative d'insérer une valeur non-unique dans une table dotée d'un index UNIQUE est rejetée.

Il est intéressant de noter que MySQL laisse également ses utilisateurs générer un index à partir des premiers (length) caractères d'une colonne CHAR ou VARCHAR. Ceci peut être utile lorsque la sélectivité des 10 premiers caractères (par exemple) d'une colonne est suffisante, et lorsqu'il est essentiel d'économiser l'espace disque.

Oracle permet de créer des index basés non seulement sur les valeurs des colonnes, mais aussi sur des expressions calculées, comme UPPER(book_name) ou ((qty * amt) / royalty). Ces index peuvent être UNIQUE ou non-uniques. Oracle permet aussi de créer un index BITMAP , ce qui est utile pour les colonnes qui n'ont pas beaucoup de valeurs distinctes. En outre, Oracle permet de générer des index ascendants ( ASC) et descendants (DESC). Toutefois, il faut noter qu'Oracle traite les index DESC comme des index basés sur des fonctions. Il y a quelques différences de fonctionnalité entre les index ASC et DESC. Il est également possible de spécifier une clé de cluster pour l'index à l'aide de l'option CLUSTER. Les clusters sont créés via la commande Oracle exclusive CREATE CLUSTER. )

La définition d'un index clusterisé varie de façon significative entre Oracle et SQL Server. Dans SQL Server, un clustered index détermine l'ordre de tri des données d'une table au plan physique. Dans Oracle, un cluster est un index spécial portant sur deux tables ou plus et qui accélère considérablement les opérations de jointure.

La clause physical_attributes_clause se rapporte aux configurations qui peuvent être établies pour les options suivantes:

PCTFREE se rapproche de l'option FILLFACTOR de SQL Server, puisqu'il précise le pourcentage d'espace à laisser libre dans l'index pour accommoder les nouvelles saisies et les mises à jour. PCTFREE ne peut être utilisé que pour les index qui ne sont pas UNIQUE. PCTUSED est le pourcentage d'espace qui doit être disponible dans un bloc pour qu'Oracle y autorise les insertions. PCTUSED peut être utilisé pour les tables, mais pas pour les index. STORAGE, INITRANS, et MAXTRANS sont décrits sous CREATE TABLE, dans cette section .

La clause TABLESPACE affecte l'index à un tablespace spécifique. Si la clause TABLESPACE est ignorée, l'index est placé dans le tablespace par défaut. Le mot-clé DEFAULT a le même effet.

LOGGING indique à Oracle d'inscrire la création de l'index dans le fichier de reprise, tandis que NOLOGGING l'en empêche. Ce mot-clé détermine également le comportement par défaut lors des chargements ultérieurs de gros volumes de données à l'aide d'Oracle Direct Loader. Lors de la mise en place de partitions d'index, ces mots-clé peuvent adopter des comportements spéciaux. Reportez-vous toujours à la documentation de l'éditeur avant de procéder à ce type d'opérations.

ONLINE signale à Oracle de permettre la manipulation des données de la table pendant la création de l'index. La commande COMPUTE STATISTICS rassemble les statistiques pendant l'opération. Le coût de la collecte des statistiques est relativement faible. COMPRESS active la compression des clés dans les index non partitionnés, ce qui libère de l'espace en éliminant les valeurs de clé répétitives. Le nombre entier qui accompagne l'option COMPRESS indique le nombre de colonnes préfixes à comprimer. NOCOMPRESS, qui constitue la configuration par défaut, désactive la compression.

Oracle permet la création d' index et de tables partitionnés via la clause PARTITION. Par conséquent, les index d'Oracle reconnaissent également les tables partitionnées. La clause LOCAL indique à Oracle de créer des index séparés pour chaque partition d'une table. La clause GLOBAL sert à créer un index commun pour toutes les partitions. L'étendue des valeurs de l'index peut différer des étendues stockées par les partitions.

L'option NOSORT permet de générer rapidement un index pour une colonne déjà triée dans l'ordre ascendant. Si les valeurs de la colonne ne sont pas dans parfaitement classées dans l'ordre ascendant, l'opération s'interrompt. Il est alors possible de réessayer sans l'option NOSORT. REVERSE, au contraire, stocke les blocs de l'index dans l'ordre inversé (sauf rowed). REVERSE et NOSORT s'excluent l'un l'autre et ne peuvent être utilisés sur un index bitmap ou une table organisée par index.

La clause PARALLEL permet d'accélérer la création de l'index en la faisant traiter par des processeurs distincts. Il est possible de définir une valeur (qui doit être un nombre entier) pour préciser le nombre exact de threads parallèles à utiliser dans l'opération. NOPARALLEL, qui constitue la configuration par défaut, signifie que l'index sera créé en série.

PostgreSQL permet la création d' index dans l'ordre ascendant standard, ainsi que d'index UNIQUE . Son implémentation inclut également une option permettant d'améliorer la performance, la clause WITH access_method. Cette clause permet d'employer l'une des trois méthodes d'accès dynamique suivantes:

• BTREE
    C'est la méthode par défaut, quand aucune autre n'est précisée. Elle utilise les arborescences-B de haute concurrence de Lehman-Yao.
• RTREE
    Cette méthode met en óuvre les arborescences-r standard avec l'algorithme de Guttman.
• HASH
    Cette méthode est une implémentation du hachage linéaire de Litwin.

Dans PostgreSQL, les colonnes peuvent aussi être associées à une classe opérateur basée sur le type de données de la colonne. Une classe opérateur précise quels sont les opérateurs pour un index particulier. Bien que les utilisateurs soient libres de définir une classe opérateur valide quelconque pour une colonne donnée, la classe opérateur par défaut est la classe appropriée à chaque type de champ.

PostgreSQL permet également de définir un index en utilisant soit une fonction, soit une fonction utilisateur, soit une expression. Par exemple, il est possible de définir un index sur UPPER(book_name) pour accélérer une opération de transformation souvent appliquée aux données de base de l'index.

Cet exemple dans MySQL crée un simple index ascendant sur la colonne au_id de la table authors:

L'exemple suivant crée une table housing_construction (comme celle de la section sur CREATE FUNCTION) et génère un index clusterisé. La clause CLUSTERED étant spécifiée, l'index trie physiquement les données sur le disque:

Il est souvent nécessaire de générer un index qui porte sur plusieurs colonnes, c'est à dire une clé composée. En voici un exemple:

En ajoutant la clause PAD_INDEX et en configurant le FILLFACTOR sur 80, on indique à SQL Server de ne remplir l'index et les pages de données qu'à 80 % au lieu de 100 %.

L'exemple ci-dessous génère le même index dans Oracle sur un tablespace précis et avec des instructions indiquant la manière spécifique dont les données doivent être stockées:

Si la table housing_construction est créée sous forme de table partitionnée sur un serveur Oracle, il convient de créer également un index partitionné:

Les procédures stockées offrent des possibilités de traitement et de programmation condionnelles dans l'environnement du serveur de base de données. Elles consistent en "capsules" de code de code programme qui peuvent accepter des paramètres saisis et exécuter des tâches complexes. De plus, elles sont pré-compilées, ce qui les rend très appréciables, puisqu'elle peuvent exécuter leurs tâches rapidement et efficacement, l'optimiseur de la base de données ayant déjà mis en place un plan d'exécution de leur code.

Comme de nombreuses autres instructions CREATE, les éditeurs ont fait preuve d'une grande diversité dans l'implémentation de cette commande.

Pour plus de détails sur la syntaxe SQL99, reportez-vous à CREATE FUNCTION. Les fonctionnalités perfectionnées de CREATE FUNCTION s'appliquent aussi à CREATE PROCEDURE.

Parce que chacun des éditeurs a implémenté ses propres extensions procédurales au langage SQL, une discussion détaillée du codage des procédures stockées dépasse le cadre de cet ouvrage. Toutefois, les notions de base de la programmation de procédures stockées y sont présentées. D'autres publications d'O'Reilly, comme Transact-SQL Programming, par Kevin Kline, Lee Gould et Andrew Zanevsky (1999), et Oracle PL/SQL Programming, Second Edition, par Steven Feuerstein avec Bill Pribyl (1997), contiennent d'excellents exposés concernant leurs langages de programmation respectifs.

En plus d'un nom de procédure, Microsoft SQL Server permet aussi de préciser un numéro de version selon le format suivant: procedure_name;1,, ou 1 est un nombre entier indiquant la version. Ceci permet d'accéder à plusieurs versions d'une mêmeprocédure stockée.

Comme pour les tables (voir CREATE TABLE), il est possible de déclarer des soniaprocédures temporaires locales et globales en ajoutant le dièse (#) ou le double dièse (##) respectivement comme préfixe au nom de la procédure. Les procédures temporaires n'existent que pour la durée de la session d'utilisateur ou de processus durant laquelle elles ont été créées. Lorsque cette session se termine, la procédure temporaire s'efface automatiquement.

Une procédure stockée SQL Server peut avoir jusqu´à 1024 paramètres d'entrée, spécifiés par un arobasae (@) et n'importe quel type de données considéré acceptable par SQL Server. Les paramètres des données de type curseur doivent être à la fois VARYING et OUTPUT. Le mot-clé VARYING n'est utilisé qu'avec les paramètres de données de type curseur pour indiquer que le jeu de résultats est généré dynamiquement par la procédure.

Les valeurs des paramètres d'entrée doivent être fournies par l'utilisateur ou par le processus d'appel. Toutefois, il est possible d'utiliser une valeur par défaut pour permettre à la procédure de s'exécuter même si l'utilisateur ou le processus n'ont pas fourni de valeur. La valeur par défaut doit obligatoirement être soit une constante, soit NULL, mais elle peut contenir des caractères génériques, comme l'explique la section LIKE.

De la même façon, un paramètre peut être déclaré paramètre de retour en utilisant le mot-clé OUTPUT. La valeur stockée dans le paramètre de retour est rapportée à chaque procédure d'appel via les variables de retour de la commande EXEC[UTE] de SQL Server. Les paramètres de sortie peuvent consister en n'importe quel type de données sauf TEXT et IMAGE.

Les options WITH RECOMPILE, WITH ENCRYPTION et WITH RECOMPILE, ENCRYPTION fonctionnent de la façon suivante:

• WITH RECOMPILE
    Indique à SQL Server de ne pas stocker le plan d'exécution dans le cache pour la procédure stockée, mais de le recompiler à chaque exécution. C'est utile lorsque la procédure emploie des valeurs atypiques ou temporaires.
• WITH ENCRYPTION
    Chiffre le code de la procédure stockée dans la table syscomments de SQL Server.
• WITH RECOMPILE, ENCRYPTION
    Permet d'utiliser simultanément les deux options.

La clause FOR REPLICATION, qui exclue WITH RECOMPILE, désactive l'exécution de la procédure stockée sur un serveur abonné. Elle est principalement utilisée pour créer une procédure stockée de filtrage qui n'est exécutée que par le moteur de réplication intégré de SQL Server.

La clause AS Transact-SQL_block contient une ou plusieurs commandes Transact-SQL, jusqu'à la taille maximum de Mo. Microsoft SQL Server autorise la plupart des instructions Transact-SQL valides, mais SET SHOWPLAN_TEXT et SET SHOWPLAN_ALL sont interdites. Certaines autres commandes voient leur utilisation limitée dans les procédures stockées. Ce sont en particulier ALTER TABLE, CREATE INDEX, CREATE TABLE, toutes les instructions DBCC, DROP TABLE, DROP INDEX, TRUNCATE TABLE et UPDATE STATISTICS.

SQL Server permet la résolution des noms différée. La procédure stockée peut donc être compilée sans erreur, même si elle fait référence à un objet qui n'a pas encore été créé. Un plan d'exécution est établi, qui n'échouera qu'au moment de l'exécution si l'objet n'existe toujours pas.

Dans SQL Server, il est facile d'imbriquer des procédures stockées. Lorsqu'une procédure stockée invoque une autre procédure stockée, la variable système @@NESTLEVEL est augmentée de 1. Elle est diminuée de 1 quand la procedure ainsi invoquée est achevée. On spécifie SELECT @@NESTLEVEL pour connaître le nombre de niveaux d'imbrication dans la session en cours.

Dans Oracle, les procédures stockées sont tout à fait similaires aux fonctions utilisateur par la composition et la structure. La différence essentielle est que les procédures stockées ne peuvent pas renvoyer de valeurs au processus d'invocation, tandis que les fonctions peuvent renvoyer une valeur unique.

Dans une procédure stockée Oracle, les arguments et paramètres spécifiés incluent IN, OUT ou IN OUT. Le qualificateur IN est fourni lorsque la fonction est invoquée et il envoie une valeur à la fonction, tandis que l'argument OUT renvoie une valeur au processus d'invocation. En d'autres termes, le qualificateur IN est fourni par l'utilisateur ou le processus qui appelle la fonction, tandis que l'argument OUT est renvoyé par la fonction. Les arguments IN OUT exécutent aussi bien les fonctionnalités de IN que de OUT. Le mot-clé NOCOPY est utile pour accélérer la performance quand un argument OUT ou IN OUT est très volumineux, comme c'est le cas pour les données de type varray ou enregistrement.

Il est aussi possible d'obliger la fonction à s'exécuter soit dans le contexte de permission de l'utilisateur actif avec l'expression AUTHID CURRENT_USER, soit dans celui du propriétaire de la fonction avec l'expression AUTHID DEFINER.

Oracle permet aussi à une procédure d'appeler des programmes externes via le mot-clé LANGUAGE. Ces programmes externes doivent être écrits en C ou en Java. La syntaxe spécifique pour ce type d'appels dépasse le cadre de cet ouvrage. Reportez-vous à la documentation de l'éditeur pour plus de renseignements sur cette fonctionnalité.

Dans Microsoft SQL Server, les procédures stockées peuvent être utilisées pour renvoyer des jeux de resultats, tandis que les procédures stockées d'Oracle ne peuvent pas renvoyer des jeux de résultats au processus d'appel.

Cette procédure stockée Microsoft SQL Server génère une valeur unique de 22 chiffres (basée sur la date et l'heure du système) et la renvoie au processus d'appel:

CREATE ROLE permet la création d'un ensemble de privilèges auquel on peut attribuer un nom, et assigner les utilisateurs de la base de données. Lorsqu'on attribue un rôle à un utilisateur, il obtient tous les privilèges et les permissions liés à ce rôle.

Microsoft SQL Server ne prend pas en charge la commande CREATE ROLE, mais offre une fonctionnalité équivalente via la procédure système stockée sp_add_role.

L'instruction ci-dessous crée un nouveau rôle et le différencie d'un utilisateur de SGBD hôte. La clause WITH ADMIN attribue instantanément un rôle à l'utilisateur ou au rôle actif. La configuration par défaut de l'instruction est WITH ADMIN CURRENT_USER.

Dans Oracle, on commence par créer un rôle, puis on lui attribue des privilèges et permissions comme s'il s'agissait d'un utilisateur, via la commande GRANT. Quand les utilisateurs veulent accéder aux permissions d'un rôle protégé par un mot de passe, ils saisissent la commande SET ROLE. Lorsqu'un rôle est doté d'un mot de passe, tout utilisateur qui souhaite y accéder doit fournir le mot de passe avec la commande SET ROLE.

Oracle est livré avec plusieurs rôles préconfigurés. CONNECT, DBA et RESOURCE sont disponibles dans toutes les versions d'Oracle. EXP_FULL_DATABASE et IMP_FULL_DATABASE sont des rôles plus récents, utilisés pour les opérations d'importation et d'exportation.

L'exemple suivant fait appel à CREATE pour spécifier un nouveau rôle dans Oracle, lui attribuer des privilèges avec GRANT, le protéger d'un mot de passe avec ALTER ROLE, et y assigner quelques utilisateurs, à nouveau avec GRANT:

Cette instruction crée un schema &8212; c.à.d., un groupe d'objets associés auquel on attribue un nom. Un schéma consiste en un assortiment de tables et de vues accompagnées de leurs permissions. Le schéma est associé à un identifiant utilisateur valide existant (appelé le propriétaire).

L'instruction CREATE SCHEMA agit comme un conteneur qui peut englober de nombreuses autres instructions CREATE et GRANT. Accessoirement, DEFAULT CHARACTER SET attribue un nom au jeu de caractères par défaut du schéma. Le chemin d'accès, PATH, peut aussi être déclaré pour tout objet du schéma qui réside sur le système de fichiers.

Si une instruction quelconque comprise dans l'instruction CREATE SCHEMA échoue, l'instruction toute entière échoue avec elle. L'avantage de CREATE SCHEMA tient à ce que les objets qu'il englobe ne doivent pas nécessairement être organisés selon un ordre de dépendance particulier. Par exemple, il est normalement impossible d'émettre une instruction GRANT pour une table qui n'existe pas encore. Toutefois, on peut commencer par placer toutes les instructions GRANT dans l'instruction CREATE SCHEMA, suivies des instructions CREATE auxquelles les premières sont attribuées.

De nombreuses implémentations ne reconnaissent pas explicitement la commande CREATE SCHEMA. Cependant, elles créent implicitement un schéma quand un utilisateur crée des objets de base de données. Oracle, quant à lui, crée un schéma chaque fois qu'un utilisateur est créé. La commande CREATE SCHEMA constitue simplement une méthode rapide pour créer en une seule étape l'ensemble des tables, vues et autres objets de base de données, ainsi que leurs permissions en une seule étape.

Dans Oracle, CREATE SCHEMA ne crée pas un schéma &8212; seul CREATE USER a cette fonctionnalité. CREATE SCHEMA permet à un utilisateur d'accomplir plusieurs étapes avec une instruction SQL unique. L'exemple ci-dessous, tiré d'Oracle, place les permissions avant les objets dans l'instruction CREATE SCHEMA:

L'instruction CREATE TABLE , comme son nom l'indique, sert à créer une table. Toutefois, la plupart des éditeurs incluent toute une série d'autres fonctions avec CREATE TABLE, comme la désignation de touches, l'intégrité référentielle en cascade, ou la définition de contraintes et de valeurs par défaut.

Cette commande définit le nom d'une table, les colonnes qui la constituent, et les propriétés des colonnes ou de la table. Habituellement, la conception et la création d'une table font l'objet d'une réflexion approfondie dans le cadre d'une discipline appelée conception de bases de données . La discipline qui consiste à analyser les relations d'une table à ses données et aux autres tables de la base de données est appelée normalisation.

Il est fortement recommandé aux programmeurs et aux développeurs de se livrer à une étude approfondie des principes qui gouvernent la conception de bases de données et la normalisation avant de se lancer dans une commande CREATE TABLE.

En général, le nom d'une table commence par un caractère alphabétique. La longueur permise varie selon les éditeurs; Oracle n'autorise que 30 caractères, mais il est possible d'en utiliser bien plus si nécessaire. On peut inclure des chiffres dans le nom d'une table, mais il est préférable de ne pas utiliser d'autre symbole que le trait de soulignement (_). Certains éditeurs permettent de nombreux autres symboles, mais il vaut mieux les éviter car ils tendent à engendrer la confusion dans les identifiants.

Pour la définition des caractéristiques de colonne, tous les éditeurs reconnaissent les options NULL et NOT NULL (une valeur NULL simple n'est pas requise dans SQL99). Lorsqu'une colonne est définie comme NULL, cette colonne peut contenir des valeurs nulles, quel que soit son type de données. Les colonnes autorisant les valeurs nulles consomment un peu plus d'espace pour chaque enregistrement. Si la clause NOT NULL est spécifiée, la colonne ne peut sous aucune circonstance contenir de valeurs nulles. Toute opération INSERT ou UPDATE sur une colonne NOT NULL qui tente soit d'introduire une valeur nulle, soit de changer une valeur existante en valeur nulle, échoue et est automatiquement annulée.

Tous les éditeurs reconnaissent aussi la déclaration PRIMARY KEY au niveau de la colonne comme de la table. La clé primaire est une désignation particulière qui permet d'identifier chaque ligne d'une table de manière unique. Elle consiste en une colonne ou une combinaison de colonnes qui fournissent à chaque ligne de la table son identité propre. Une table ne peut avoir qu'une seul clé primaire. Toutes les valeurs de la clé primaire doivent être uniques, et aucune ne peut être nulle. Il est alors possible de déclarer des clés étrangères, qui établissent une relation directe avec la clé primaire d'une autre table. Ceci permet de créer des relations parent/enfant ou table master/table détaillée entre les tables. Une action en cascade peut augmenter cette action. Par exemple, un utilisateur peut souhaiter empêcher que l´enregistrement d'un client soit effacé de la table customer s'il existe des enregistrements pour ce client dans la table sales. La syntaxe des clés étrangères varie selon l'éditeur.

La plupart des éditeurs reconnaissent aussi l'attribution d'une valeur par défaut DEFAULT pour une colonne donnée. Si un enregistrement est créé sans qu'aucune valeur soit fournie pour la colonne en question, sa valeur par défaut est automatiquement insérée.

La syntaxe de base pour l'instruction CREATE TABLE est montrée ci-dessous; ceci est suffisant pour commencer à créer des tables et à les remplir de données:

Voici un exemple simple:

Dans Microsoft SQL Server, cette instruction définit une table appelée housing_construction qui comprend huit colonnes. Chaque colonne est définie soit comme NULL,soit comme NOT NULL, avec le type de données correspondant au type d'information qu'elle contient. A noter: la liste des définitions de colonnes apparaît toujours entre parenthèses et une virgule termine chaque définition de colonne lorsqu'elle est suivie d'une autre définition.

L'instruction CREATE TABLE SQL99 crée des tables temporaires TEMPORARY qui sont instanciées quand la table est créée et automatiquement éliminées quand la session d'utilisateur en cours se termine. Une table temporaire peut être GLOBAL, et donc accessible par tous les utilisateurs ayant des sessions en cours, ou LOCAL, et donc accessible uniquement par l'utilisateur qui l'a créée. Il est également possible de préciser une valeur ON COMMIT pour une table temporaire. ON COMMIT PRESERVE ROWS préserve toutes les modifications apportées aux données de la table temporaire lors de l'opération de validation COMMIT, tandis que ON COMMIT DELETE ROWS efface la table après le COMMIT.

L'option LIKE table_name crée une nouvelle table avec les mêmes définitions de colonnes et les mêmes contraintes qu'une table déjà existante. Lorsque LIKE est utilisé, il n'est pas nécessaire de définir les contraintes de table ou de colonnes.

Parce que CREATE TABLE est une commande d'importance capitale, et parce que son implémentation varie considérablement d'un éditeur à l'autre, elle est décrite séparément et en détail pour chaque SGBD.

SQL Server offre quantité d'options pour la définition d'une table, de ses colonnes, et de ses contraintes de table. Il permet entre autres d'attribuer un nom aux contraintes de colonnes en spécifiant CONSTRAINT constraint_name.. ., suivi du texte de la contrainte. Il est possible d'appliquer plusieurs contraintes à une même colonne, à condition qu'elles ne soient pas mutuellement exclusives (comme c'est le cas par exemple pour PRIMARY KEY et NULL ).

SQL Server permet aussi de créer une table temporaire stockée dans la base de données tempdb en précédant le nom de la table d'un dièse (#) unique. La table temporaire locale peut être utilisée par la personne ou par le processus qui l'a créée. Elle est automatiquement effacée quand la personne ferme sa session ou quand le processus s'achève. Une table temporaire globale utilisable par toutes les personnes et tous les processus qui ont des sessions ouvertes peut être établie en précédant le nom de la table de deux dièses (##). La table temporaire globale est effacée lorsque son processus s'achève ou que son créateur ferme sa session.

Comme SQL Server admet la réplication intégrée, de nombreuses propriétés d'une colonne peuvent être configurées sur NOT FOR REPLICATION, ce qui signifie que les valeurs d'une colonne IDENTITY ou d'une clé étrangère (FOREIGN KEY) ne seront pas répliquées sur les serveurs abonnés. Ceci est utile dans les situations où différents serveurs utilisent les mêmes structures de table, mais pas les mêmes données.

ROWGUIDCOL est également utile en cas de réplication. Ceci désigne une colonne comme identificateur global unique, ce qui permet d'assurer que deux valeurs ne peuvent en aucun cas être répétées quel que soit le nombre de serveurs. Il ne peut y avoir qu'une seule colonne de ce type par table. Toutefois, les valeurs uniques ne sont pas automatiquement créées. Elles doivent être insérées à l'aide de la fonction NEWID.

La propriété IDENTITY, appliquée à une colonne de nombre entiers, est similaire à AUTO_INCREMENT dans MySQL: elle crée et remplit automatiquement la colonne d'un nombre qui s'accroît de façon monotone. Elle est cependant plus souple. Alors qu'AUTO_INCREMENT démarre toujours à 1, IDENTITY commence à compter à partir de la valeur seed fixée au départ. Et alors qu'AUTO_INCREMENT augmente de 1 à chaque nouvel enregistrement, IDENTITY augmente de la valeur incrémentale définie dans increment.

Dans SQL Server, DEFAULT peut s'appliquer à n'importe quelle colonne, à l'exception de celles dont le type de données est une référence temporelle ou qui sont dotées d'une propriété IDENTITY. DEFAULT doit être à la fois une valeur constante (par exemple, une chaîne de caractères, ou un nombre donné) et une fonction système (comme GETDATE( ) ou NULL).

Pour chaque table, une clé PRIMARY KEY appelée nom par table, ainsi que plusieurs colonnes UNIQUE ou plusieurs clés FOREIGN KEY peuvent également être spécifiées. Elles peuvent être clusterisées ou non, et définies avec un facteur de remplissage de départ. Reportez-vous à la section concernant CREATE INDEX pour plus de détails.

Lorsqu'une FOREIGN KEY est spécifiée, la table et les colonnes chargées de conserver l'intégrité référentielles peuvent être désignées via la clause REFERENCES. Cette clause ne peut faire référence qu'à des colonnes qui ont été définies comme PRIMARY KEY ou index UNIQUE sur la table référençante. Il est possible de définir une action référentielle qui doit s'exécuter sur la reference_table quand un enregistrement est effacé ou mis à jour. Si la clause NO ACTION est spécifiée, alors la table référencée ne fait l'objet d'aucune action quand un enregistrement est effacé ou mis à jour. Si la clause CASCADE est spécifiée, alors l'opération d'effacement ou de mise à jour s'applique aussi à tout enregistrement de la table référencée qui dépend de la valeur de la clé FOREIGN KEY.

La contrainte CHECK permet de s'assurer qu'une valeur saisie dans la colonne spécifiée de la table constitue une valeur possible selon l'expression CHECK. Cet exemple montre une table comportant plusieurs contraintes de colonne:

La contrainte CHECK placée sur la colonne people_id permet de s'assurer qu'elle ne contiendra que des valeurs alphabétiques, tandis que celle placée sur la colonne zip garantit des valeurs entièrement numériques. La contrainte REFERENCES sur la colonne state consulte la table states. La contrainte REFERENCES est pratiquement identique à la contrainte CHECK, hormis le fait qu'elle obtient sa liste de valeurs possibles parmi les valeurs stockées dans une autre colonne. Cet exemple illustre bien la façon dont on attribue des noms aux contraintes de colonne, via la syntaxe CONSTRAINT constraint_name.

La propriété de colonne COLLATE est également une nouveauté dans SQL Server 2000. Elle permet aux programmeurs de modifier, colonne par colonne, l'ordre de tri et le jeu de caractères utilisés par la colonne. Comme il s'agit d'une technique complexe, reportez-vous à la documentation de l'éditeur pour plus de détails. La section consacrée à CREATE FUNCTION contient un exemple de la syntaxe à employer.

SQL Server permet également la création de tables dotées de colonnes qui contiennent une valeur calculée. Ces colonnes ne contiennent pas réellement de données. En fait, il s'agit de colonnes virtuelles qui contiennent une expression qui utilise d'autres colonnes déjà présentes dans la table. Par exemple, une colonne calculée peut avoir une expression du type order_cost AS (price * qty). Le contenu d'une colonne calculée peut aussi consister en une constante, une fonction, une variable, une colonne non-calculée, ou n'importe lesquelles de ces possibilités combinées entre elles avec des opérateurs.

Toutes les contraintes de colonne décrites ci-dessus peuvent également être déclarées au niveau de la table. C'est à dire que les contraintes PRIMARY KEY, FOREIGN KEY, CHECK, ou autres peuvent être déclarées lorsque toutes les colonnes ont été définies dans l'instruction CREATE TABLE. Ceci est très utile pour les contraintes qui couvrent plus d'une colonne. Par exemple, quand une contrainte de colonne UNIQUE est déclarée, elle ne peut être appliquée qu'à la colonne pour laquelle elle a été créée. Si, en revanche, la contrainte est déclarée au niveau de la colonne, elle peut s'appliquer à plusieurs colonnes. Voici un exemple de contraintes de colonne et de table:

Ces deux commandes donnent des résultats pratiquement identiques, la seule différence étant que la contrainte de table UNIQUE englobe deux colonnes, tandis que la contrainte de colonne UNIQUE ne concerne qu'une seule colonne.

Enfin, Microsoft SQL Server dispose de deux clauses distinctes qui permettent de contrôler le placement physique de la table (ou de la clé primaire, ou des index uniques): [ON {filegroup | DEFAULT}] et [TEXTIMAGE_ON {filegroup | DEFAULT}]. La clause ON filegroup stocke la table ou l'index dans le groupe de fichiers désigné à condition qu'il soit situé dans la base de données. Si ON DEFAULT est spécifié ou si la clause ON n'est pas utilisée, la table ou l'index sont stockés dans le groupe de fichiers par défaut de la base de données. La clause TEXTIMAGE fonctionne à peu près de la même façon, sauf qu'elle contrôle le placement des colonnes de type text, ntext, et image. Ces colonnes sont normalement stockées dans le groupe de fichiers par défaut avec le reste des tables et des objets de base de données.

MySQL dispose de nombreuses options pour la création de tables. L'option TEMPORARY crée une table qui existe pendant la durée de la session au cours de laquelle elle a été créée. Une fois que la connexion est fermée, la table temporaire est automatiquement effacée. L'option IF NOT EXISTS empêche toute erreur possible au cas où la table existerait déjà.

Quand une table est créée dans MySQL, trois fichiers sont automatiquement créés dans le système d'exploitation: une définition de table portant l'extension .frm, un fichier de données avec l'extension .myd, et un fichier index avec l'extension .myi.

La clause AUTO_INCREMENT définit une colonne de nombres entiers qui augmentent automatiquement de 1 (avec 1 pour valeur de départ). MySQL ne permet qu'une seule colonne AUTO_INCREMENT par table. Quand la valeur maximale est effacée, elle est réutilisée. Quand tous les enregistrements sont effacés, les valeurs reviennent au point de départ.

Une ou plusieurs colonnes PRIMARY KEY peuvent être définies, à condition qu'elles soient aussi définies comme NOT NULL. Quand une caractéristique INDEX est attribuée à une colonne, il est possible d'y inclure un nom pour l'index (dans MySQL, KEY est synonyme d'INDEX). Si aucun nom n'est attribué, MySQL en crée un composé d'index_column_name suivi d'un suffixe numérique ( _2, _3,... ) pour en garantir l'unicité. Seules les tables de type MyISAM acceptent les index sur les colonnes NULL ou sur les colonnes de type BLOB ou TEXT.

Les clauses FOREIGN KEY, CHECK et REFERENCES sont inopérantes. Elles n'ajoutent aucune fonctionnalité à la table, et ne sont prises en charge que pour assurer la compatibilité avec les autres bases de données SQL.

Les options de table TYPE déterminent le mode de stockage physique des données. ISAM est la définition de table d'origine. MyISAM est une nouvelle structure de stockage binaire, plus portable. HEAP stocke la table dans la mémoire. Il existe d'autres options permettant d'optimiser les performances de la table:

• AUTO_INCREMENT
    Définit la valeur incrémentale automatique auto_increment pour la table (MyISAM uniquement).
• AVG_ROW_LENGTH
    Définit une longueur de ligne moyenne approximative pour les tables qui comprennent des enregistrements de taille variable. MySQL utilise avg_row_length * max_rows pour décider de la taille maximale d'une table.
• CHECKSUM
    Configuré avec une valeur de 1, vérifie par sommation toutes les lignes de la table (MyISAM uniquement). Ralentit le traitement, mais réduit les risques de corruption.
• COMMENT
    Permet d'introduire un commentaire comptant jusqu´à 60 caractères.
• DELAY_KEY_WRITE
    Configuré avec une valeur de 1, retarde les mises à jour jusqu´à la fermeture de la table (MyISAM uniquement).
• MAX_ROWS
    Définit un nombre maximum de lignes à stocker dans la table. Le maximum par défaut est de 4 Go.
• MIN_ROWS
    Définit un nombre minimum de lignes à stocker dans la table.
• PACK_KEYS
    Configuré avec une valeur de 1, compacte les index de la table, ce qui accélère la lecture mais ralentit les mises à jour (MyISAM et ISAM uniquement). Par défaut, les chaînes sont seules à être condensées. Configuré avec une valeur de 1, les valeurs numériques sont également condensées.
• PASSWORD
    Protège le fichier .frm d'un mot de passe, mais pas la table.
• ROW_FORMAT
    Détermine comment les lignes devront être stockées dans la table à l'avenir.

La clause SELECT_statement crée une table dont les champs sont basés sur les éléments de l'instruction SELECT. Si ce n'est pas le cas, comme cela arrive dans certaines implémentations, alors la table peut être peuplée avec les résultats de l'instruction SELECT. Par exemple:

Ceci crée une table heap avec trois colonnes: column_a, column_b et column_c.

Ce bloc de code paraît court et simple, mais c'est une impression trompeuse ! L'implémentation de l'instruction CREATE TABLE dans Oracle est extrêmement élaborée, et pourrait même être qualifiée de commande la plus complexe de tous les langages de programmation.

Le code de la clause CREATE TABLE dans Oracle contient de nombreuses sous-clauses. Plutôt que de les montrer toutes dans une seule commande, la commande est décomposée en sous-clauses qui à leur tour contiennent d'autres sous-clauses. La plupart des programmeurs SQL n'auront jamais l'occasion d'utiliser ces sous-clauses.

Pour donner une idée des différences les plus évidentes entre la version SQL99 et la version Oracle de CREATE TABLE, notons que les tables créées avec GLOBAL TEMPORARY doivent être les tables les plus simples. Les tables temporaires globales sont privées de la plupart des caractéristiques spéciales qu'Oracle autorise pour les tables ordinaires, comme le partitionnement, l'indexation, ou la clusterisation. Une table temporaire globale est accessible à partir de toutes les sessions ouvertes, mais les données qui y sont stockées ne sont visibles que par la session qui les y a insérées. La clause ON COMMIT, qui n'est autorisée que lors de la création de tables temporaires, indique à Oracle soit de tronquer la table après chaque validation (DELETE ROWS), soit d'attendre que la session s'achève (PRESERVE ROWS). Par exemple:

L'instruction CREATE TABLE montrée ci-dessus crée une table temporaire globale, shipping_schedule, qui conserve les lignes insérées sur plusieurs sessions.

Les caractéristiques physiques d'une table Oracle sont définies via les quelques blocs de code et leurs sous-blocs:

La clause physical_characteristics contrôle le mode de stockage physique des données sur le sous-système de disque.

La clause TABLESPACE attribue à la table un tablespace spécifique. La clause TABLESPACE peut être ignorée, plaçant ainsi l'index sur le tablespace par défaut. Le mot-clé DEFAULT donne le même résultat.

Les clauses LOGGING et NOLOGGING déterminent s'il faut inscrire une table, un objet de grande taille (LOB) ou une partition dans le fichier de reprise.

La clause ORGANIZATION HEAP indique à Oracle que les lignes de la table peuvent être rangées dans n'importe quel ordre. Elle peut être associée à une clause segment_characteristic. Les lignes de la table peuvent également être rangées selon un index spécifique avec ORGANIZATION INDEX index_name.

La clause physical_attributes (comme le montre le bloc de code ci-dessous) définit les caractéristiques de stockage pour la table dans son entier ou, si la table est partitionnée, pour une partition spécifique (voir détails plus loin):

PCTFREE définit le pourcentage d'espace libre attribué à chaque bloc de données de la table. Par exemple, une valeur de 10 permet de réserver 10 % de l'espace pour l'insertion de nouvelles lignes. PCTUSED définit le pourcentage d'espace minimum pour qu'un bloc soit autorisé à recevoir de nouvelles lignes. Par exemple, une valeur de 90 signifie que de nouvelles lignes sont insérées dans le bloc de données quand l'espace utilisé est inférieur à 90 %. La somme de PCTFREE et PCTUSED ne peut pas dépasser 100. La clause INITRANS est rarement modifiée; elle définit l'allocation de 1 à 255 transactions initiales à un bloc de données. MAXTRANS définit le nombre maximum de transactions simultanées sur un bloc de données.

storage_clause contrôle un certain nombre d'attributs relatifs au stockage physique des données:

Lors de leur définition, les attributs de la clause de stockage doivent être encadrés de parenthèses et séparés par des espaces (par exemple, (INITIAL 32M NEXT8M)). INITIAL int [K | M] précise la taille du premier extent de la table en octets, kilooctets (K) ou megaoctets (M). NEXT int [K | M] indique combien d'espace supplémentaire allouer une fois que INITIAL est rempli. PCTINCREASE int contrôle le taux d'augmentation des objets après la croissance initiale. Le premier extent est alloué selon les spécifications. Le second est de la taille précisée par NEXT. La taille du troisième correspond à NEXT + (NEXT * PCTINCREASE). Si PCTINCREASE comporte une valeur de 0, c'est la taille définie par NEXT qui est utilisée. Sinon, chaque nouvel extent d'un espace de stockage est plus grand que le précédent de la valeur définie par PCTINCREASE.

MINEXTENTS int demande à Oracle de créer un nombre minimum d'extents. Par défaut, Oracle n'en crée qu'1 seul, mais peut en créer plus lorsque l'objet est initialisé. MAXEXTENTS int détermine le nombre maximum d'extents autorisé. Ce nombre peut être UNLIMITED (mais il convient d'utiliser l'option UNLIMITED avec prudence: dans certaines situations, elle peut endommager la base de données). FREELISTS int établit le nombre de listes libres pour chaque groupe, 1 étant la valeur par défaut. FREELIST GROUPS int détermine le nombre de groupes de listes libres, 1 étant la valeur par défaut. Par exemple:

La table books_sales est définie sur le tablespace sales comme nécessitant 8 Mo d'espace initial, et programmée pour augmenter d'au moins 8 Mo lorsque le premier extent sera plein. La table n'a pas moins d'1 extent mais pas plus de 8. Sa taille maximum est donc de 64 Mo.

La clause ORGANIZATION HEAP permet à Oracle de placer physiquement les lignes de la table dans n'importe quel ordre. En option, elle peut être associée à une clause segment_characteristic_clause. Ou encore, les lignes de la table peuvent être ordonnées physiquement selon un INDEX nommé.

La clause CLUSTER ajoute la table à un cluster existant, basé sur une clé clusterisée. Reportez-vous à la section concernant la commande CREATE CLUSTER d'Oracle. Toutes les tables du cluster doivent comporter des colonnes qui correspondent aux colonnes de la clé clusterisée.

special_storage_clause détaille trois styles de stockage des données possibles dans une table Oracle: LOB (objets de grande taille, par ex. fichiers images), varrays et tables imbriquées:

La clause LOB définit les attributs de stockage d'un segment de données LOB. L'article LOB est le nom de la (ou des) colonne(s) LOB déclarées dans la table. Les objets LOB de moins de 4000 octets peuvent êtres stockés dans la ligne même via la clause ENABLE STORAGE IN ROW. Quelle que soit leur taille, ils peuvent également être stockés en dehors de la ligne avec la clause DISABLE STORAGE IN ROW. Reportez-vous à la documentation Oracle pour plus d'informations sur le stockage des LOB avec LOB_storage_clause. Par exemple:

La table large_objects sert à stocker des images et du texte. Les caractéristiques de stockage, tout comme les caractéristiques de tenue du journal et de cache, sont également détaillées.

Un varray est un objet spécifique à Oracle. Oracle permet des paramètres de stockage différents pour les LOB stockés dans un varray, avec une syntaxe pour ainsi dire identique à celle de la clause LOB. Reportez-vous à la documentation de l'éditeur pour plus d'informations sur les varrays.

Oracle permet de déclarer une clause NESTED TABLE selon laquelle une table est stockée virtuellement dans une colonne d'une autre table. La clause STORE AS permet de créer un nom de table proxy pour la table imbriquée, mais celle-ci doit d'abord être créée comme un type de données utilisateur. Cette approche peut être utile pour les tableaux de valeurs incomplets, mais elle n'est pas recommandée au quotidien. Par exemple:

Oracle permet de définir toutes sortes de caractéristiques pour une table donnée. En voici quelques unes:

Oracle utilise la clause PARTITION pour améliorer les performances en déployant la table sur plusieurs partitions. La syntaxe décrivant toutes les permutations possibles lors de la partition d'une table est trop longue pour être intégralement reprise ici. D'autre part, elle est rarement utilisée par les programmeur SQL débutants. Reportez-vous à la documentation d'Oracle pour plus d'informations sur le partitionnement des tables.

CACHE tamponne une table pour permettre une lecture rapide, tandis que NOCACHE annule la mise en mémoire tampon. Les tables dotées d'index permettent d'utiliser l'option CACHE. MONITORING recueille les statistiques d'une table pour améliorer les performances. NOMONITORING annule cette fonction.

Pour l'instruction CREATE TABLE, la clause INDEX est réservée aux clés primaires et aux index uniques créés avec la table. Reportez-vous à la documentation Oracle pour une explication détaillée des options de manipulation des index qu'offre la commande CREATE TABLE. Dans la plupart des cas, il est préférable d'utiliser la commande CREATE INDEX. A noter: Oracle indexe automatiquement les tables dotées d'une contrainte de clé primaire. Il n'est pas nécessaire à l'utilisateur de créer un index dans cette situation.

La clause PARALLEL permet d'accélérer la création d'une table en la faisant traiter en parallèle par des processeurs distincts. Elle permet également d'utiliser le parallélisme pour effectuer des requêtes et d'autres opérations de manipulation des données sur la table une fois celle-ci créée. Il est possible de définir une valeur (qui doit être un nombre entier) pour préciser le nombre exact de threads parallèles à utiliser dans l'opération de création, ainsi que les opérations futures sur la table. Comme Oracle calcule le nombre optimal de threads à utiliser pour une opération en parallèle donnée, cette sélection est optionnelle. NOPARALLEL, qui constitue la configuration par défaut, signifie que la table sera créée en série et n'autorise pas les requêtes et opérations de manipulation des données en parallèle pour l'avenir.

Les clauses ENABLE et DISABLE sont utilisées pour activer ou désactiver les contraintes d'une table. La clause DISABLE peut désactiver n'importe quelle contrainte d'intégrité ou n'importe quel trigger actif. A l'inverse, ENABLE peut activer n'importe quelle contrainte d'intégrité ou n'importe quel trigger désactivé. La syntaxe de la clause est la suivante:

Le mot-clé CASCADE, qui ne peut être utilisé qu'avec DISABLE, ne sert pas à désactiver une contrainte ou un trigger en cascade. En fait, son rôle est d'étendre la désactivation ou l'activation à toutes les contraintes d'intégrité qui dépendent de la contrainte nommée dans la clause. La clause EXCEPTIONS INTO, qui ne peut être utilisée qu'avec ENABLE, indique à Oracle de stocker les informations concernant toute violation d'une contrainte d'intégrité dans une table des exceptions existante. La clause USING INDEX, qui ne peut également être utilisée qu'avec ENABLE, fournit un mécanisme permettant de spécifier certaines caractéristiques de stockage pour l'index désigné, en particulier des clés primaires et uniques. Par défaut, toutes les contraintes sont activées.

La clause AS SELECT_statement peuple la nouvelle table d´enregistrements provenant d'une instruction SELECT valide. Contrairement à l'implémentation de CREATE... AS SELECT dans PostgreSQL, les colonnes de l'instruction CREATE TABLE doivent correspondre à celles de l'instruction SELECT. L'enregistrement au journal de CREATE... AS SELECT peut être annulé avec le mot-clé NOLOGGING. Par défaut, l'opération est inscrite dans le fichier de reprise.

En outre, Oracle prend en charge un certain nombre de fonctions orientées objet qui dépassent le cadre de cet ouvrage.

Avec une syntaxe similaire à celle de MySQL, PostgreSQL permet la création d'une table temporaire TEMPORARY. Les tables temporaires n'existent que pour la durée de la session pendant laquelle elles ont été créées, et s'effacent automatiquement quand la session est close.

Les contraintes comme UNIQUE, PRIMARY KEY et CHECK sont essentiellement les mêmes que dans Microsoft SQL Server. Toutefois, PostgreSQL a l'unique capacité de créer des contraintes de colonnes sur plusieurs colonnes. Néanmoins, comme PostgreSQL prend aussi en charge les contraintes de table standard, il est recommandé d'employer l'approche décrite par la norme ANSI.

La contrainte REFERENCES fonctionne un peu comme une contrainte CHECK, sauf qu'elle compare une valeur aux valeurs d'une autre colonne, dans une autre table. Elle peut aussi être incluse dans une déclaration FOREIGN KEY. Les options de correspondance MATCH sont FULL (complète), PARTIAL, (partielle) ou l'option par défaut (où MATCH n'a pas d'autre mot-clé). La correspondance complète contraint toutes les colonnes d'une clé étrangère à contenir soit une valeur nulle, soit une valeur admissible. Par défaut, les valeurs nulles peuvent être mélangées aux valeurs non nulles. La syntaxe de la correspondance partielle est valide, mais l'option n'est pas prise en charge.

La clause REFERENCES permet aussi de déclarer plusieurs comportements différents pour l'intégrité référentielle ON DELETE ou ON UPDATE:

• NO ACTION
    Produit une erreur lorsque la clé étrangère est enfreinte (option par défaut).
• RESTRICT
    Un synonyme de NO ACTION.
• CASCADE
    Copie la valeur de la colonne référencée dans la colonne référençante.
• SET NULL
    Configure la valeur de la colonne référençante sur NULL.
• SET DEFAULT
    Configure la colonne référençante sur sa valeur par défaut déclarée, ou sur null s'il n'y a pas de valeur par défaut.

L'option DEFERRABLE de la clause REFERENCES indique à PostgreSQL de différer toutes les contraintes jusqu´à la fin d'une transaction. Par défaut, le comportement de la clause REFERENCES est NOT DEFERRABLE. La clause INITIALLY est similaire à la clause DEFERRABLE. INITIALLY DEFERRED vérifie les contraintes après chaque transaction; INITIALLY IMMEDIATEles vérifie après chaque instruction (configuration par défaut).

A noter: comme dans Microsoft SQL Server, les contraintes de colonnes peuvent toutes être déclarées comme contraintes de table. La contrainte FOREIGN KEY ne peut être déclarée que comme contrainte de table et non comme contrainte de colonne. Toutes les options de la clause REFERENCES sont prises en charge sous l'égide de la clause FOREIGN KEYS. Voici la syntaxe:

La clause INHERITS inherited_table désigne une ou plusieurs tables où cette table hérite de toutes ses colonnes. La nouvelle table hérite aussi des fonctions rattachées aux tables situées plus haut dans la hiérarchie. Si une certaine colonne héritée apparaît plus d'une fois, l'instruction échoue.

Si une table temporaire ou table temporaire globale est créée dans PostgreSQL, la clause ON COMMIT peut être ajoutée à la commande. Cette clause contrôle le comportement de la table temporaire après que les enregistrements aient été validés dans la table. ON COMMIT DELETE ROWS efface toutes les lignes de la table temporaire après chaque validation. C'est le comportement par défaut. ON COMMIT PRESERVE ROWS sauvegarde les lignes de la table temporaire après la validation de la transaction.

La clause AS SELECT_statement permet à un programmeur de créer et de peupler une table avec des données provenant d'une instruction SELECT valide. Il n'est pas nécessaire de définir les colonnes, types de données ou contraintes, puisqu'ils sont tous hérités de la requête. La fonctionnalité de cette clause est similaire à celle de SELECT... INTO, mais sa syntaxe semble plus lisible.

Le code ci-dessous ajoute une clé étrangère à la table de l'exemple:

La clé étrangère sur la colonne categories la rattache à la table cat_name au sein de la table category. Cette syntaxe est admise par les SGDB de tous les éditeurs mentionnés dans cet ouvrage. De même, la clé étrangère aurait pu être déclarée comme une clé à plusieurs colonnes et inclure les colonnes category et subcategory:

Voici deux exemples complets supplémentaires, tirés de la base de données pubs (jobs et employee):

L'exemple qui suit est une instruction CREATE TABLE Oracle dotée de nombreuses propriétés de stockage:

Les triggers constituent une catégorie spéciale de procédures stockées qui se déclenchent automatiquement (d'où le nom "trigger": gâchette ou déclencheur, en français) quand une instruction de modification des données est exécutée. Les triggers sont associés à une instruction de modification des données spécifique (INSERT, UPDATE ou DELETE) sur une table spécifique.

Par défaut, les triggers ne se déclenchent qu'une seule fois au niveau de l'instruction. En d'autres termes, une instruction INSERT peut insérer 500 lignes dans une table, mais un trigger d'insertion sur la même table ne se déclenche qu'une fois. Certains éditeurs permettent de déclencher un trigger pour chaque ligne touchée par la manipulation des données. Ainsi, une instruction qui insère 500 lignes dans une table dotée d'un trigger d'insertion au niveau de la ligne se déclenche 500 fois, une par ligne insérée.

En plus d'être associé à une instruction de modification des données spécifique (INSERT, UPDATE ou DELETE) sur une table donnée, le déclenchement d'un trigger est également associé à un moment spécifique. En général, les triggers peuvent se déclencher soit avant (BEFORE), soit après (AFTER), soit, si l'éditeur l'autorise, à la place (INSTEAD OF) d'une instruction de modification des données. Les triggers qui se déclenchent avant ou à la place de l'instruction ne voient pas les changements qu'elle provoque, tandis que ceux qui se déclenchent après peuvent voir ces changements et agir en conséquence.

Microsoft SQL Server introduit un certain nombre de fonctionnalités intéressantes dans son instruction CREATE TRIGGER. Tout d'abord, SQL Server permet d'associer plusieurs triggers à une même opération de manipulation des données sur une table ou une vue. Ainsi, il est possible d'assigner trois triggers UPDATE à une même table.

La clause WITH ENCRYPTION chiffre le texte du trigger à l'emplacement où il est stocké dans la table système syscomments. La clause WITH APPEND ajoute un nouveau trigger d'un type déjà existant à une table ou une vue. Cette clause est ajoutée pour permettre la compatibilité rétroactive avec des versions plus anciennes de ce produit, et ne peut être utilisée qu'avec les triggers FOR. La clause NOT FOR REPLICATION désactive le trigger pour les opérations de manipulation des données invoquées via les options de réplication intégrées de SQL Server.

Les clauses FOR, AFTER et INSTEAD OF indiquent à SQL Server quand déclencher le trigger. Les mots-clé FOR et AFTER sont synonymes et servent les mêmes fonctions. Leur rôle est de préciser que le trigger ne doit se déclencher qu'après l'exécution complète et réussie de l'instruction de modification des données à laquelle ils sont rattachés (ainsi que de toute action en cascade ou vérification de contrainte potentielle). Une table donnée peut accepter de nombreux triggers AFTER. Bien que l'ordre de déclenchement ne soit pas défini, il est possible d'identifier le premier et le dernier via la procédure système stockée sp_settriggerorder.

Il est impossible de définir des triggers AFTER sur les vues.

La clause INSTEAD OF fonctionne de la même manière que le trigger BEFORE d'Oracle. Elle indique que le trigger doit se déclencher avant (et donc à la place de) l'instruction de modification des données à laquelle il est rattaché. Bien qu'une même instruction INSERT, UPDATE ou DELETE sur une table donnée accepte plusieurs triggers AFTER, elle ne peut recevoir qu'un seul trigger INSTEAD OF. Ce type de trigger peut être utilisé sur les vues, mais seulement si elles ne sont pas dotées d'une clause WITH CHECK OPTION. Les triggers INSTEAD OF DELETE ne peuvent être utilisés quand l'effacement est assorti d'une action en cascade.

Les clauses DELETE, INSERT et UPDATE désignent l'instruction de modification des données qui déclenche le trigger. Dans une définition de trigger SQL Server, elles peuvent être associées de toutes les façons possibles. Il suffit de les séparer d'une virgule. Le même code se déclenche alors pour chaque instruction dans la définition combinée.

La clause AS T-SQL_block contient le code procédural déclenché par le trigger chaque fois que la manipulation des données a lieu. Elle devrait être incluse dans les clauses BEGIN et END de Transact-SQL. Elle contient habituellement les commandes de contrôle de flux et vérifie le type et le nombre de données modifiées.

Quand un trigger est déclenché, SQL Server instancie deux pseudo-tables: deleted et inserted. Ces tables présentent la même structure que la table sur laquelle les triggers sont définis, à la différence que l'une recèle les données telles qu'elles étaient avant le déclenchement de l'instruction (deleted) et l'autre, les nouvelles valeurs de la table après son exécution (inserted).

Seuls les triggers INSTEAD OF peuvent accéder à des colonnes text, ntext ou image.

La clause AS IF UPDATE(column) vérifie l'existence d'actions de type INSERT ou UPDATE sur une ou plusieurs colonnes données. Il est possible de spécifier plusieurs colonnes en ajoutant des clauses UPDATE(column) après la première. Faire suivre la clause d'un bloc BEGIN... END Transact-SQL pour permettre le déclenchement de plusieurs opérations Transact-SQL lorsque la condition existe. D'un point de vue fonctionnel, cette clause est équivalente à l'opération IF... THEN... ELSE.

La clause AS IF (COLUMNS_UPDATE( )) est similaire à AS IF UPDATE( ) en ce qu'elle ne se déclenche que lorsqu'une opération INSERT ou UPDATE touche la colonne désignée. Elle renvoie une chaîne binaire varbinary qui indique les colonnes insérées ou mises à jour et permet des opérations sur les bits pour comparer les valeurs des colonnes de diverses manières. Les opérateurs de comparaison sont le signe égal (=), pour vérifier si toutes les colonnes mentionnées dans le masque binaire mis à jour ont bien été modifiées, et le signe «  plus grand que » (>), pour vérifier si une ou plusieurs des colonnes ont été modifiées.

Les triggers sont souvent utilisés pour contrôler l'intégrité référentielle. Toutefois, il est préférable de déclarer les clés primaires et étrangères via une instruction CREATE TABLE ou ALTER TABLE.

SQL Server ne permet pas d'inclure les instructions suivantes dans le bloc Transact-SQL d'un trigger: ALTER, CREATE, DROP, DENY, GRANT, REVOKE, LOAD, RESTORE, RECONFIGURE ou TRUNCATE. En outre, les instructions DISK et les commandes UPDATE STATISTICS ne sont pas non plus autorisées.

SQL Server permet aussi aux triggers de se déclencher de manière récursive via la configuration recursive triggers de la procédure système stockée sp_dboption. Les triggers récursifs s'auto-déclenchent par leurs propres actions. Par exemple, si un trigger INSERT rattaché à la table T1 procède à une opération INSERT sur la table T1, il peut exécuter une opération récursive. Les triggers récursifs présentent un risque, et cette fonctionnalité est donc désactivée par défaut.

De la même façon, SQL Server permet les triggers imbriqués triggers jusqu´à 32 niveaux. Si l'un quelconque des triggers imbriqués procède à un ROLLBACK, les triggers suivants ne s'exécuteront pas. On parle de triggers imbriqués lorsque, par exemple, un trigger rattaché à la table T1 déclenche une opération sur la table T2, elle-même dotée d'un trigger qui déclenche une opération sur la table T3. Si une boucle sans fin est lancée, les triggers s'annulent automatiquement. Les triggers imbriqués sont activés via la configuration "nested triggers" de la procédure système stockée sp_configure. Si les triggers imbriqués sont désactivés, les triggers récursifs le sont également, même si sp_dboption comporte la configuration «  recursive triggers ».

Les instructions CREATE de SQL Server autorisent la résolution de noms différée , ce qui signifie que la commande est traitée même si elle se réfère à un objet qui n'existe pas encore dans la base de données.

Comme c'est souvent le cas avec l'instruction CREATE TRIGGER, la commande spécifie la modification des données qui déclenche le bloc de code PL/SQL (INSERT, UPDATE ou DELETE) et le moment de son déclenchement &8212; avant (BEFORE), après (AFTER) ou à la place de (INSTEAD OF) l'opération. Pour les opérations UPDATE, un UPDATE OF d'une ou plusieurs colonnes peut être spécifié pour indiquer que le trigger de mise à jour ne devrait se déclencher que si l'une de ces colonnes est modifiée.

Dans Oracle, les triggers INSTEAD OF ne peuvent s'exécuter que sur les vues, et non sur les tables.

Oracle permet aussi le déclenchement de triggers associés à certains évènements de la base de données comme DROP TABLE ou SHUTDOWN.

La clause REFERENCING attribue un nom aux pseudo-tables qui contiennent l'ancienne (OLD) et la nouvelle (NEW) version de la table (dans SQL Server, les pseudo-tables sont automatiquement nommées inserted et deleted). Dans Oracle, les noms par défaut de ces pseudo-tables sont OLD et NEW. Elles comparent les valeurs des enregistrements avant la manipulation des données (dans la pseudo-table OLD) aux valeurs résultant de l'opération (dans la pseudo-table NEW). Elles exécutent aussi des opérations conditionnelles sur le PL/SQL_block.

Lorsqu'il est fait référence à une valeur provenant des tables OLD et NEW, cette valeur doit être précédée des deux points (:), sauf dans la clause WHEN du trigger, où les deux points ne sont pas utilisés.

La clause FOR EACH ROW indique au trigger d'intervenir sur chaque ligne (il se déclenche une fois pour chaque ligne affectée par l'opération), plutôt que d'opérer comme un trigger d'instruction implicite (qui ne se déclenche qu'une fois pour toute la transaction). La clause WHEN définit une condition SQL qui limite l'exécution du trigger aux seules situations où la condition est remplie. La clause WHEN permet aussi de comparer les tables OLD et NEW sans avoir à créer un bloc PL/SQL.

Il est possible de combiner différents types de triggers dans une même commande trigger à condition qu'ils soient de même niveau (ligne ou instruction) et qu'ils portent sur la même table. Quand plusieurs triggers sont ainsi combinés dans une même instruction, les clauses IF INSERTING THEN, IF UPDATING THEN et IF DELETING THEN peuvent être utilisées dans le bloc PL/SQL pour scinder la logique du code en segments distincts. Une clause ELSE peut aussi trouver sa place dans une telle structure.

L'implémentation de CREATE TRIGGER dans PostgreSQL fonctionne de façon similaire à celle des autres éditeurs. Un trigger peut se déclencher avant (BEFORE) que la modification des données de l´enregistrement soit entamée et que les contraintes soient déclenchées. Ou il peut se déclencher après (AFTER) la manipulation des données (et après que les contraintes aient été vérifiées), auquel cas il peut prendre en compte toutes les opérations de la transaction.

Plutôt que de traiter un bloc de code procédural (comme le font Oracle et SQL Server), PostgreSQL exécute une fonction via la clause EXECUTE PROCEDURE créée avec l'instruction CREATE FUNCTION. En outre, les autres éditeurs traitent implicitement toutes les lignes concernées par la transaction. PostgreSQL exécute le trigger soit sur chaque ligne avec la clause FOR EACH ROW, soit une seule fois pour toute la transaction avec la clause FOR EACH INSTRUCTION.

L'exemple ci-dessous montre un trigger BEFORE dans PostgreSQL qui vérifie que le code de distributeur spécifié pour chaque ligne correspond bien à un code de la table distributors avant d'insérer ou de mettre à jour une ligne dans la table sales:

Les triggers BEFORE modifient les valeurs d'une table affectées par une opération de modification des données puisque le traitement des enrgistrements concernés se produit avant qu'ils soient modifiés dans la table. Comme ils ne peuvent pas se déclencher avant que la ligne ait été modifiée dans la table, les triggers AFTER sont souvent utilisés pour auditer les processus. INSTEAD OF supprime complètement la modification des données et y substitue un code fournit par l'utilisateur pour la transaction.

Voici un trigger BEFORE dans Oracle qui utilise les pseudo-tables OLD et NEW pour comparer les valeurs (SQL Server utilise les pseudo-tables DELETED et INSERTED de la même façon). Ce trigger crée un enregistrement d'audit avant de modifier l´enregistrement des salaires d'un employé:

L'exemple ci-dessous produit un trigger d'insertion et de mise à jour dans Oracle qui utilise les clauses IF INSERTED THEN:

Cet exemple tiré de SQL Server ajoute une nouvelle table intitulée contractor à la base de données. Tous les enregistrements de la table employee qui indiquent que l'employé est sous contrat temporaire ont été déplacés vers la table contractor. Maintenant, tous les nouveaux employés insérés dans la table employee vont être déplacés vers la table contractor via un trigger INSTEAD OF:

Cette instruction crée une vue, ou table virtuelle. Une vue agit exactement comme une table, mais elle est en fait définie comme une requête. Presque n'importe quelle instruction SELECT valide peut définir le contenu d'une vue, excepté la clause ORDER BY, qui est en général interdite.

Quand une vue est référencée dans une instruction, le jeu de résultats provenant de la requête devient le contenu de la vue pour la durée de l'instruction. Dans certains cas, les vues peuvent être mises à jour. Les changements de la vue sont alors répercutés sur les données sous-jacentes des tables de base.

Les vues peuvent même être créées à partir d'autre vues, mais cette pratique n'est pas recommandée.

Les vues ont en général le même degré d'efficacité que les requêtes sur lesquelles elles sont basées. C'est pourquoi il est important de bien s'assurer que l'instruction SELECT dont elles proviennent est rapide et bien écrite.

Il est aussi possible de définir une liste de colonnes après le nom de la vue. La liste facultative de colonnes contient des alias qui servent de nom pour chaque élément du jeu de résultats de l'instruction SELECT.

La clause WITH CHECK OPTION n'est utilisée que pour les vues qui permettent de modifier la table de base. Elle permet de s'assurer que seules les données que la vue puisse insérer, mettre à jour ou effacer sont celles auxquelles elle a accès en lecture. Par exemple, si une vue des employees ne montre que les employés à plein temps et non les employés payés à l´heure, il est impossible d'insérer, de mettre à jour ou d'effacer des employés payés à l´heure à partir de cette vue. Les options CASCADE et LOCAL de la clause CHECK OPTION sont utilisées pour les vues imbriquées. L'option CASCADE procède à la vérification pour la vue en cours et toutes les vues à partir desquelles elle est créée. L'option LOCAL ne vérifie que la vue en cours, même si elle est créée à partir d'autres vues.

Les vues ANSI SQL99 peuvent mettre à jour les tables de base à partir desquelles elles sont créées si elles satisfont aux conditions suivantes:

1. L'instruction SELECT dont provient la vue est basée sur une table.
2. La vue ne comporte pas d'opérateurs UNION, MINUS ou INTERSECT.
3. L'instruction SELECT dont elle provient ne contient pas de clauses GROUP BY ou HAVING.
4. L'instruction SELECT dont elle provient ne contient aucune référence à des pseudo-colonnes comme ROWNUM ou ROWGUIDCOL.
5. L'instruction SELECT dont elle provient ne contient aucune fonction de groupe.
6. L'instruction SELECT dont elle provient ne contient pas la clause DISTINCT.

Microsoft SQL Server ajoute deux nouvelles options à la norme SQL99: ENCRYPTION et SCHEMABINDING. L'option ENCRYPTION chiffre le texte de la vue dans la table syscomments. L'option SCHEMABINDING lie la vue à un schéma spécifique, ce qui oblige tous les objets de la vue à être référencés par leur nom complet (nom du propriétaire et nom de l'objet). Les vues créées avec SCHEMABINDING (et les tables auxquelles elles font référence) doivent être dégagées du schéma (avec ALTER VIEW) avant de pouvoir être effacées ou modifiées. VIEW_METADATA indique que SQL Server renvoie des métadonnées sur la vue aux demandes des API DBLIB et OLEDB (au lieu de la table de base). Les vues créées ou altérées avec VIEW_METADATA permettent la mise à jour de leurs colonnes par des triggers INSERT et UPDATE INSTEAD OF.

SQL Server permet d'indexer les vues (voir CREATE INDEX). Créer un index unique clusterisé sur une vue revient à faire stocker par SQL Server une copie physique de la vue sur la base de données. Les modifications apportées à la table de base sont automatiquement mises à jour dans la vue indexée.

Les vues indexées ne devraient être créées à partir de tables de base qu'avec la clause SCHEMABINDING. Il s'agit d'une technique complexe qu'il vaut mieux réserver aux experts. Reportez-vous à la documentation de l'éditeur pour plus d'information.

La clause OR REPLACE demande à Oracle de remplacer toute vue existante portant le même nom par la nouvelle vue. La clause FORCE crée une vue sans se soucier de savoir si les tables de base existent ou si l'utilisateur dispose de privilèges lui permettant d'y accéder. La clause NO FORCE ne crée la vue que si les tables de base et les privilèges appropriés sont en place.

Oracle permet d'utiliser CHECK OPTION, y compris la possibilité nommer la contrainte avec la clause CONSTRAINT. CHECK OPTION peut être utilisée pour les vues imbriquées, mais seulement si elle est appliquée sur la vue de niveau supérieur. Si la contrainte n'est pas nommée, Oracle lui attribue le nom SYS_Cn, où n est un nombre entier.

Oracle permet de manipuler les données dans les vues, à condition que les spécifications de la norme SQL99 soient respectées, et que la spécification supplémentaire ne contienne aucune expression. La clause WITH READ ONLY assure que la vue n'est utilisée que pour récupérer des données.

L'instruction CREATE VIEW dans PostgreSQL ne prend pas en charge certaines des fonctions les plus complexes offertes par les autres éditeurs, mais elle permet de créer des vues à partir de tables et d'autres objets de classes définies. En général, les vues PostgreSQL sont créées à partir d'autres tables plutôt que d'autres vues. Elle ne sont pas utilisées pour procéder à la modification des données contenues dans les tables de base sous-jacentes.

La vue la plus simple est basée sur l'intégralité du contenu d'une seule table:

Cet exemple montre une vue intitulée california_authors qui ne permet que les modifications appliquées aux auteurs vivant en Californie:

La commande DECLARE CURSOR permet la récupération et la manipulation des enregistrements d'une table, ligne à la fois. Ceci permet d'adopter un mode de traitement ligne par ligne plutôt que le traitement par jeu traditionnellement offert dans SQL. Pour utiliser correctement cette procédure, il faut:

1. Déclarer le curseur (DECLARE).
2. Ouvrir le curseur (OPEN).
3. extraire les lignes du curseur (FETCH).
4. Quand l'opération est terminée, fermer le curseur (CLOSE)

MySQL ne prend pas en charge les curseurs serveur tels qu'ils sont définis dans la norme ANSI, mais propose de nombreuses extensions de programmation en C qui fournissent les mêmes fonctionnalités.

La commande DECLARE CURSOR fonctionne par la définition d'une instruction SELECT. Chaque ligne renvoyée par l'instruction SELECT peut être récupérée et manipulée individuellement. La commande DECLARE CURSOR définit également les caractéristiques d'un curseur serveur. Ces caractéristiques peuvent inclure le défilement du curseur et l'instruction SELECT utilisée pour récupérer un jeu de résultats.

Microsoft SQL Server permet d'identifier l'option INSENSITIVE et l'option SCROLL. Le mot-clé INSENSITIVE indique que le curseur doit créer une copie temporaire du jeu de résultats qu'il utilise. Toutes les requêtes qui lui sont adressées reçoivent leur réponse à partir de la table temporaire et non de la table de base. Le curseur ne permet pas d'effectuer de modifications. Les extractions ultérieures du curseur ne reflètent aucun des changements qu'il effectue. Le mot-clé SCROLL active toutes les options FETCH du curseur (FIRST, LAST, PRIOR, NEXT, RELATIVE et ABSOLUTE). Reportez-vous à la commande FETCH pour plus de détails. Si SCROLL n'est pas déclaré, la seule option FETCH disponible est NEXT. Un curseur en lecture seule peut aussi être déclaré avec la clause FOR READ ONLY.

Dans Oracle, les variables ne sont autorisées dans la clause WHERE de l'instruction SELECT que si elles ont d'abord été déclarées comme variables. Les valeurs des paramètres ne sont pas définies au DECLARE, mais à la commande OPEN.

L'implémentation de PostgreSQL est en tous points similaire à celle de Microsoft SQL Server, sauf qu'elle permet une option BINARY. BINARY oblige le curseur à récupérer les données au format binaire plutôt qu'au format texte.

Microsoft SQL Server prend en charge le format standard décrit plus haut, mais offre aussi une extension plus élaborée. La syntaxe pour cette dernière est:

Cette syntaxe fonctionne de la même façon que la déclaration de curseur de la norme ANSI, mais elle offre de nombreuses fonctionnalités nouvelles. Premièrement, l'étendue du curseur peut être soit LOCAL, soit GLOBAL. Si LOCAL est sélectionné, le curseur n'est disponible que dans le cadre du lot, de la procédure stockée ou du trigger Transact-SQL au cours duquel il a été déclaré. Si GLOBAL est sélectionné, le curseur est disponible comme les commandes OPEN et FETCH pour toute la connexion.

Ne pas confondre la notation Transact-SQL avec la déclaration de curseur de la norme ANSI sous Microsoft SQL Server.

Les options suivantes déterminent le mode de recherche du curseur dans le jeu d´enregistrements. FORWARD_ONLY, contrairement à SCROLL, implique que le curseur ne peut défiler que du premier au dernier enregistrement. Cette option ne peut pas être utilisée en conjonction avec STATIC, KEYSET ou DYNAMIC. Il agit comme un curseur DYNAMIC.

STATIC fonctionne de manière similaire au mot-clé INSENSITIVE. KEYSET rappelle STATIC et INSENSITIVE, mais permet d'effectuer des modifications sur le jeu de résultats. Il n'est pas conscient des enregistrements insérés par d'autres utilisateurs après l'ouverture du curseur, mais les enregistrements effacés produisent une variable @@FETCH_STATUS de -2. Les nouvelles valeurs deviennent visibles lorsque les mises à jour sont exécutées en spécifiant WHERE CURRENT OF. DYNAMIC reflète tous les changements subis par les données du jeu de résultats pendant la session sur le curseur. Le jeu de résultats peut changer pendant n'importe quel FETCH. FETCH ABSOLUTE n'est pas pris en charge par les curseurs DYNAMIC. FAST_FORWARD est un raccourci pour FORWARD_ONLY, READ_ONLY, mais il offre aussi des fonctionnalités supplémentaires. FAST_FORWARD et SCROLL, FOR_UPDATE, SCROLL_LOCKS, OPTIMISTIC et FORWARD_ONLY sont mutuellement exclusifs.

Deux autres options sont également permises pour READ_ONLY: SCROLL_LOCKS et OPTIMISTIC. SCROLL_LOCKS impose un verrou au niveau des enregistrements chaque fois qu'un nouvel enregistrement est extrait. Ceci permet d'assurer que les mises à jour et les effacements exécutés via le curseur sont effectifs. OPTIMISTIC implique que les mises à jour et les effacements positionnés exécutés via le curseur échouent si la ligne est modifiée par un autre utilisateur.

Enfin, l'option TYPE_WARNING demande à SQL Server d'envoyer un message d'avertissement au client si le curseur passe d'un type à un autre (par exemple, de KEYSET à DYNAMIC).

Dans ce simple exemple tiré de Microsoft SQL Server, un curseur de la table publishers est déclaré et ouvert. Le curseur prend le premier enregistrement de publisher qui correspond à l'instruction SELECT et l'insère dans une autre table, puis passe à l´enregistrement suivant, puis au suivant et ainsi de suite, jusqu´à ce que tous les enregistrements aient été traités. Alors, le curseur est fermé et libéré (deallocate ne s'utilise que dans Microsoft SQL Server):

Dans cet exemple tiré d'Oracle, le curseur est déclaré avec d'autres variables dans le bloc de déclaration, puis le reste du curseur est traité:

Comme cet exemple utilise beaucoup de PL/SQL, une grande partie du code dépasse le cadre de cet ouvrage. Cependant, le bloc DECLARE montre clairement que le curseur est déclaré. Dans le bloc d'exécution PL/SQL, le curseur est initialisé avec la commande OPEN, les valeurs sont récupérées avec la commande FETCH, et enfin, le curseur est libéré avec la commande CLOSE.

L'instruction DELETE efface les enregistrements d'une ou de plusieurs tables désignées. L'opération est inscrite au journal, ce qui signifie qu'elle peut être annulée avec une commande ROLLBACK.

On émet rarement une instruction DELETE sans une clause WHERE, parce que cela aurait pour effet d'effacer toutes les lignes de la table concernée.

S'il s'avère nécessaire d'effacer toutes les lignes d'une table, il est préférable d'utiliser l'instruction TRUNCATE TABLE. Dans les bases de données qui reconnaissent cette commande, c'est souvent une méthode plus rapide pour retirer physiquement toutes les lignes. TRUNCATE TABLE est plus rapide que DELETE parce que TRUNCATE n'est pas inscrit au journal, ce qui rend l'annulation impossible. Le simple fait de supprimer l'inscription au journal permet de gagner un temps considérable lors de l'effacement d'un grand nombre d´enregistrements.

Microsoft SQL Server permet d'effacer des enregistrements aussi bien des tables que des vues correspondant à une table unique. Certaines règles permettent d'effacer les enregistrements d'une vue multitable, mais elles sont assez complexes, et dépassent le cadre de cet ouvrage. A deux endroits dans la commande, après le premier FROM et à la fin de l'instruction, il est possible d'outrepasser le comportement par défaut de l'optimiseur de SQL Server, mais cette manóuvre devrait être réservée aux experts. Ces conseils ne figurent pas dans la norme ANSI, mais on les trouve dans la documentation de la plupart des éditeurs.

En outre, SQL Server permet une seconde clause FROM. Ce second FROM permet l'utilisation de l'instruction JOIN et facilite l'effacement de lignes dans le premier FROM (en se basant sur les lignes correspondantes d'une table déclarée dans le second FROM).

La clause WHERE CURRENT OF est utilisée pour positionner les effacements via un curseur. De concert avec le curseur, cette forme de DELETE n'efface que la ligne ouverte dans le curseur.

MySQL est optimisé pour une plus grande vitesse. Dans cette optique, il permet de préciser LOW PRIORITY, ce qui retarde l'exécution de DELETE jusqu´à ce que la table ne soit plus consultée par d'autres clients. MySQL peut aussi limiter arbitrairement le nombre d´enregistrements qu'il efface avant de rendre le contrôle au client, via la clause LIMIT nbr_of_rows.

Oracle permet d'effacer des lignes des tables et des vues simples, ainsi que des tables et des vues partitionnées.

PARTITION et SUBPARTITION indiquent le nom de la partition ou de la sous-partition à effacer au sein de la table.

La clause WITH est utilisée en conjonction avec une sous-requête. Elle limite les actions de l'instruction DELETE. L'option WITH READ ONLY précise que les sous-requêtes utilisées dans la commande ne peuvent pas être mises à jour. WITH CHECK OPTION demande à Oracle d'effacer (DELETE) toute ligne ne figurant pas dans la sous-requête.

RETURNING extrait les lignes affectées par la commande. Quand elle est utilisée pour effacer une seule ligne, les valeurs de la ligne sont stockées dans des variables PL/SQL et des variables attachées. Quand elle est utilisée pour effacer plusieurs lignes, les valeurs des lignes sont stockées dans des tableaux attachés. Le mot-clé INTO signifie que les valeurs effacées doivent être stockées dans la liste de variables.

PostgreSQL utilise la commande DELETE pour effacer des lignes et des sous-classes définies de la table. Pour n'effacer de lignes que de la table désignée, il faut utiliser la clause ONLY. La clause WHERE CURRENT OF demande à PostgreSQL de n'effacer que la ligne actuellement ouverte du curseur en cours.

Pour effacer tous les enregistrements de la table titles:

Pour effacer tous les enregistrements dont le nom de famille commence par «  Mc » de la table authors:

Pour effacer tous les titres dotés d'un code d'identification obsolète:

Pour effacer tous les titres qui ne se vendent pas:

Pour effacer tous les enregistrements d'une table sur la base des résultats d'une sous-requête sur une autre table (dans le cas présent, tous les enregistrements de la table titleauthor qui correspondent à des enregistrements portant sur le sujet «  ordinateurs » dans la table titles sont effacés):

L´instruction DISCONNECT met fin à une connexion au SGBD.

Cette commande permet de mettre fin à une ou plusieurs connexions créées entre le processus SQL en cours et le serveur de base de données. La clause CURRENT ferme la connexion utilisateur active. La clause ALL ferme toutes les connexions ouvertes pour l´utilisateur actuel. Vous pouvez aussi fermer uniquement une connexion spécifique.

Microsoft SQL Server prend uniquement en charge DISCONNECT dans Embedded-SQL (ESQL), mais pas dans son outil de requête ponctuel, SQL Query Analyzer. Il prend en charge la syntaxe SQL99 complète. Lorsque vous quittez Microsoft SQL Server dans un programme ESQL, vous devez veiller à utiliser la commande DISCONNECT ALL pour assurer une déconnexion correcte du serveur de base de données.

Contrairement à SQL Server, Oracle autorise uniquement l´emploi de la commande DISCONNECT dans son outil de requête ponctuel, SQL*Plus. Dans ce cas, la commande met fin à la session en cours avec le serveur de base de données; cependant, elle permet la poursuite des opérations dans SQL*Plus. Par exemple, un programmeur peut continuer à modifier la mémoire tampon, à enregistrer des fichiers d´exécution, et ainsi de suite. Une nouvelle connexion est toutefois nécessaire pour pouvoir utiliser les commandes SQL. Les commandes EXIT ou QUIT sont nécessaires pour quitter SQL*Plus et revenir au système de fichiers.

Oracle prend également en charge cette fonctionnalité avec la commande ALTER SYSTEM DISCONNECT SESSION. Il s´agit cependant d´une commande spéciale que seul l´administrateur de base de données peut employer pour imposer la déconnexion d´une session (souvent extérieure) à la base de données.

PostgreSQL ne prend pas explicitement en charge la commande DISCONNECT. Cependant, les interfaces de programmation prennent toujours en charge une opération de déconnexion; par exemple, SPI_FINISH dans la Server Programming Interface ou PG_CONNECT dans l'outil de programmation PL/tcl.

Pour mettre fin à la connexion en cours à un serveur Oracle:

Microsoft SQL Server prend uniquement en charge la commande DISCONNECT dans les programmes ESQL:

DROP DATABASE annule toutes les opérations exécutées au moyen de la commande CREATE DATABASE . Cette instruction élimine tous les objets de la base de données et libère l´espace qu´ils occupaient. La plupart des éditeurs ne permettent pas l´exécution de cette commande lorsque des utilisateurs (le propriétaire, notamment) effectuent des opérations sur la base de données.

A l´instar de CREATE DATABASE, la commande DROP DATABASE est uniquement prise en charge par ANSI SQL en tant qu´extension (mais non en tant que commande de base). SQL99 utilise de préférence les commandes relatives à SCHEMA et DOMAIN pour couvrir les domaines correspondant en gros à ce que les implémentations assimilent généralement à des questions de « base de données  ».

Vous ne devez jamais supprimer les bases de données système créées par l´éditeur. A moins d´être exécuté par le propriétaire de la base de données ou l´administrateur système, l´élimination d´une base de données exige des permissions explicites.

SQL Server permet d´éliminer plusieurs bases de données en même temps; il vous suffit de séparer leur nom par une virgule. Seuls un utilisateur de la base de données master, un utilisateur possédant les privilèges de l´administrateur système ou le propriétaire de la base de données peuvent éliminer une base de données. L´élimination est uniquement possible avec les bases de données de type ONLINE.

Dans MySQL et PostgreSQL, cette commande supprime intégralement la base de données et tous les fichiers associés. La base de données envoie un message indiquant le nombre de fichiers qui ont été supprimés. Il est impossible de supprimer une base de données ouverte et en cours d´utilisation dans le cadre de l´implémentation PostgreSQL.

Oracle ne prend pas en charge la commande DROP DATABASE. La suppression d´une base de données exige l´émission de la commande CREATE DATABASE database_name (sans aucun paramètre), dans laquelle database_name correspond au nom de la base de données que vous voulez supprimer.

Cette commande élimine de la base de données active une fonction définie par l´utilisateur.

Cette commande permet de supprimer définitivement une fonction. La clause RESTRICT entraîne toujours l´échec de la commande si d´autres objets de la base de données (une vue, par exemple), dépendent de la fonction en question. En revanche, l´option CASCADE élimine la fonction, les droits reposant sur cette fonction et les objets de base de données connexes !

Comme avec les autres commandes DROP de SQL Server, il est possible d´éliminer plusieurs objets de base de données du même type en séparant leur nom par une virgule.

Cette commande ne supprime pas le fichier qui contient la fonction. En revanche, elle supprime la référence à cette fonction de la table système; l´instruction CREATE FUNCTION permet de restaurer cette référence.

Comme avec les autres commandes DROP d´Oracle, il est possible de spécifier le nom du propriétaire de la fonction. Sinon, Oracle considère que la suppression porte uniquement sur le contexte utilisateur courant, ainsi que sur les fonctions que cet utilisateur possède. En outre, les utilisateurs qui disposent du privilège système DROP ANY FUNCTION peuvent supprimer n´importe quelle fonction, à tout emplacement.

PostgreSQL permet de supprimer les fonctions déclarées dans n´importe quel langage de programmation. Type représente l´argument d´entrée de la fonction à supprimer. Il faut spécifier le type, puisque seule la fonction possédant le nom et les types de paramètres indiqués sera supprimée.

La commande DROP INDEX supprime un ou plusieurs index dans la base de données active. Lorsqu´un index est éliminé, l´espace qu´il occupait est immédiatement récupéré. Cependant, DROP INDEX ne supprime pas les contraintes PRIMARY KEY ou UNIQUE, pour lesquelles il faut utiliser la commande ALTER TABLE . . . DROP. Reportez-vous à la commande CREATE TABLE pour de plus amples informations sur les contraintes uniques et les contraintes de clé primaire.

PostgreSQL respecte la norme SQL99, avec certaines variations.

Microsoft SQL Server permet d´éliminer les index créés aussi bien dans les tables que dans les vues. Lorsqu´un index clusterisé est éliminé dans une table qui contient également des index non clusterisés, ces derniers sont recréés et ils reçoivent de nouveaux pointeurs.

Les anciennes versions de MySQL incluent uniquement cette commande pour des raisons de compatibilité; en revanche, les nouvelles versions permettent de supprimer l´index spécifié. D'un point de vue fonctionnel, cette instruction est équivalente à l´instruction ALTER TABLE . . . DROP INDEX de MySQL.

MySQL permet de supprimer plusieurs index; il suffit pour ce faire de séparer par une virgule les noms de table et d´index.

Oracle permet d´éliminer directement les index en fonction de leur nom (il est inutile d´indiquer le nom de la table). Oracle permet également de d´éliminer l´index sur la base du nom du propriétaire.

Cette commande permet de supprimer une procédure stockée dans la base de données utilisateur active.

Cette commande est pratiquement similaire à DROP FUNCTION, sauf qu´elle s´applique aux procédures stockées, et non aux fonctions.

Microsoft SQL Server permet de supprimer plusieurs procédures stockées en même temps; il suffit pour ce faire de séparer leur nom par une virgule. Il est impossible d´éliminer des procédures individuelles; seul le groupe entier de procédures stockées peut être supprimé.

Oracle permet également d´éliminer n´importe quelle procédure sur la base du nom de son propriétaire. Les utilisateurs qui disposent du privilège système DROP ANY PROCEDURE peuvent éliminer les procédures que les autres utilisateurs possèdent.

Cette commande permet de supprimer un ensemble nommé de privilèges utilisateur dans la base de données utilisateur active.

La commande DROP ROLE supprime le rôle spécifié. Seuls les utilisateurs disposant du privilège WITH ADMIN OPTION peuvent supprimer des rôles.

L´exécution de la commande DROP ROLE supprime le rôle dans la base de données utilisateur active. Les utilisateurs ou les rôles auxquels ce rôle spécifique était précédemment attribué ne pourront plus l´employer.

Cette commande permet de supprimer une définition de table, ainsi que tous les index, données, triggers, contraintes et spécifications de permissions connexes. Les vues ou procédures stockées qui font référence à la table éliminée rencontreront des problèmes, sauf si elles sont explicitement modifiées ou éliminées.

Pour certains éditeurs, il faut d´abord supprimer d´autres caractéristiques spécifiques de la table pour pouvoir éliminer celle-ci. Dans Microsoft SQL Server, par exemple, il faut supprimer la table dans les schémas de réplication et les références FOREIGN KEY avant de pouvoir éliminer la table à proprement parler.

Dans la syntaxe SQL99, RESTRICT ne permet pas au SGBD d´exécuter la commande si des vues ou des contraintes font référence à la table à éliminer. La clause CASCADE permet de supprimer tous les objets référençants avec la table.

Microsoft SQL Server permet d´éliminer plusieurs tables en même temps; il suffit de ce faire de séparer leur nom par une virgule. Il permet également de supprimer des tables dans les bases de données, en dehors de leur contexte actuel; il convient pour ce faire spécifier le nom de la base de données (cette opération suppose que l´utilisateur dispose des permissions appropriées). Les contraintes ou les triggers associés à la table sont éliminés avec cette dernière. Les valeurs par défaut et les règles explicitement déclarées perdent leurs liaisons lorsque leur table sous-jacente est éliminée. Les vues et les procédures stockées qui font référence à la table éliminée renvoient une erreur lorsque la table reste introuvable pendant leur exécution.

MySQL supprime définitivement l´intégralité de la table et tous les fichiers associés à l´exécution de cette commande. L´ajout de la syntaxe IF EXISTS permet de prévenir le renvoi d´un message d´erreur susceptible de s´afficher lorsque l´utilisateur essaie de supprimer une table qui n´existe peut-être pas.

Dans Oracle, l´élimination d´une table libère l´espace qu´elle occupait et valide les modifications en attente dans la base de données. Lorsqu´une table est éliminée, l´espace qu´elle occupait est immédiatement récupéré. Les index et les droits associés à cette table sont perdus. Les objets créés à partir de la table (vues, procédures stockées et synonymes, notamment), sont marqués comme non valides et ils cessent de fonctionner.

N´oubliez pas que, dans Oracle, l´exécution d´une commande ALTER, CREATE ou DROP entraîne la validation des autres transactions en attente.

La clause CASCADE CONSTRAINTS supprime toutes les contraintes d´intégrité renvoyant aux clés de la table éliminée.

PostgreSQL prend uniquement en charge la commande DROP TABLE de base.

La commande DROP TRIGGER supprime un trigger associé à une table de la base de données active.

La commande DROP TRIGGER supprime un trigger de la base de données active. MySQL ne prend pas cette commande en charge.

Microsoft SQL Server permet d´éliminer plusieurs triggers en même temps; il suffit pour ce faire de séparer leur nom par une virgule.

Oracle élimine le trigger spécifié et valide les modifications en attente dans la base de données lors de l´exécution de cette commande.

PostgreSQL exige que la table contenant le trigger soit nommée. Il élimine alors toutes les références à un trigger existant lors de l´exécution de cette commande.

Cette supprime définitivement une vue de la base de données active.

Dans la syntaxe SQL99, RESTRICT indique au SGBD d´interdire l´élimination si des vues ou des affirmations font référence à la table à supprimer. La clause CASCADE permet d´éliminer tous les objets référençants avec la vue.

Cette commande n´est pas prise en charge par MySQL pour le moment.

Microsoft SQL Server permet de supprimer plusieurs vues en même temps; il suffit pour ce faire de séparer leur nom par une virgule. Les vues doivent appartenir à la même base de données. Les informations concernant cette vue sont supprimées de toutes les tables système.

A l´instar des autres commandes DROP d´Oracle, cette commande permet de spécifier le nom du propriétaire avec le nom de la vue. Les utilisateurs qui disposent du privilège système DROP ANY VIEW peuvent éliminer les vues que les autres utilisateurs possèdent.

Dans PostgreSQL, la commande DROP VIEW élimine une vue existante de la base de données active. Seul le propriétaire de la vue peut l´éliminer. La commande DROP TABLE de PostgreSQL permet également d´éliminer des vues.

La commande FETCH est l´une des quatre commandes applicables aux processus de curseur. FETCH récupère une ligne spécifique d´un curseur serveur.

La commande FETCH récupère un enregistrement à partir du cursor_name (créé par l´instruction DECLARE CURSOR), sur la base du mot-clé NEXT, PRIOR, FIRST, LAST, ABSOLUTE ou RELATIVE. Les valeurs récupérées par l´instruction FETCH peuvent être stockées dans des variables. Les opérations FETCH sont les suivantes:

• NEXT
    Indique au curseur de revenir à l´enregistrement qui suit directement la ligne active, et incrémente cette dernière sur la ligne renvoyée. FETCH NEXT est le comportement par défaut de FETCH: cette instruction récupère le premier enregistrement s´il est exécuté en tant que première extraction pour un curseur. (PostgreSQL utilise le mot-clé FORWARD ou la chaîne FETCH RELATIVE NEXT.)
• PRIOR
    Indique au curseur de revenir à l´enregistrement qui précède directement la ligne active, et décrémente cette dernière sur la ligne renvoyée. FETCH PRIOR ne récupère pas d´enregistrement si ce dernier est exécuté en tant que première extraction pour un curseur. (PostgreSQL utilise le mot-clé BACKWARD ou la chaîne FETCH RELATIVE PRIOR.)
• FIRST
    Indique au curseur de revenir à son premier enregistrement pour en faire la ligne active. (Cette opération n´est pas prise en charge par PostgreSQL.)
• LAST
    Indique au curseur de revenir à son dernier enregistrement pour en faire la ligne active. (Cette opération n´est pas prise en charge par PostgreSQL.)
• ABSOLUTE { n }
    Indique au curseur de renvoyer le ne enregistrement du jeu d´enregistrements du curseur, à partir du début (si n est positif) ou de la fin (si n est négatif); l´enregistrement renvoyé deviendra ainsi le nouvel enregistrement du curseur. Si n est égal à 0, aucune ligne n´est renvoyée. (Cette opération n´est pas prise en charge par PostgreSQL.)
• RELATIVE { n }
    Indique au curseur de renvoyer les n lignes de l´enregistrement qui suivent (si n est positif) ou précèdent (si n est négatif) l´enregistrement; l´enregistrement renvoyé deviendra ainsi le nouvel enregistrement du curseur. Si n est égal à 0, la ligne active est renvoyée. (Cette opération est prise en charge conformément à la description de PostgreSQL, sauf si n est égal à 0.)

Le mot-clé INTO permet de placer dans une variable locale les données provenant de chacune des colonnes de la commande FETCH. Chaque colonne de la commande FETCH est associée à une variable de type de données correspondant dans la clause INTO. (INTO n´est pas prise en charge par PostgreSQL.)

Les curseurs PostgreSQL sont uniquement utilisés dans les transactions explicitement déclarées, au moyen de BEGIN, COMMIT ou ROLLBACK. PostgreSQL permet de récupérer un nombre spécifique ou la totalité des enregistrements; il suffit pour ce faire d´indiquer le nombre voulu ou le mot-clé ALL.

Les curseurs Oracle sont des curseurs en avant seulement. Ils doivent soit insérer les valeurs récupérées dans les variables correspondantes, soit, au moyen de la clause BULK COLLECT, appliquer une liaison globale à la sortie avant de la renvoyer à l´analyseur PL/SQL. La commande FETCH est souvent associée à une boucle FOR PL/SQL pour traiter l´ensemble des lignes du curseur.

Les curseurs PostgreSQL sont uniquement utilisés dans les transactions explicitement déclarées, au moyen de BEGIN, COMMIT ou ROLLBACK.

Le curseur peut avoir un défilement de type FORWARD, BACKWARD ou RELATIVE. La clause RELATIVE peut inclure tout ou partie des enregistrements à récupérer; cette indication est signalée par un nombre ou par le mot-clé ALL.

L´exemple Oracle qui suit récupère plusieurs éléments de employee_new_hires_cursor (reportez-vous à l´exemple sous DECLARE CURSOR) dans plusieurs variables locales:

La commande PostgreSQL qui suit récupère cinq enregistrements de la table employee:

Dans SQL99, l´instruction GRANT permet aux utilisateurs et aux rôles d´accéder aux objets de base de données et de les utiliser. De plus, les éditeurs de base de données utilisent généralement l´instruction GRANT pour permettre aux utilisateurs et aux rôles de créer des objets et d´exécuter des procédures stockées, des fonctions, et ainsi de suite.

Avec l´instruction GRANT, les utilisateurs peuvent se voir attribuer un ou plusieurs privilèges d´accès &8212; SELECT, INSERT, UPDATE, DELETE, REFERENCES ou USAGE &8212; par une autorité compétente. Chacun de ces privilèges permet à l´utilisateur d´exécuter la commande spécifiée, tandis que REFERENCES et USAGE accordent d´autres privilèges. Pour spécifier plusieurs privilèges d´accès, il suffit de séparer chacun d´eux par une virgule; ALL permet d´accéder à tous les privilèges. Le mot-clé PRIVILEGES est optionnel.

Le privilège USAGE s´applique à tout objet de base de données, à l´exception des tables, tandis que les autres privilèges s´appliquent uniquement aux tables. Le privilège USAGE permet aux utilisateurs de créer des objets sur la base de la définition d´un autre objet; il est ainsi possible, par exemple, de créer une collation sur la base d´une translation. Le privilège REFERENCES permet d´utiliser une table incluse dans une contrainte ou une clé étrangère.

Les privilèges INSERT, UPDATE, et REFERENCES peuvent être attribués aux colonnes spécifiques d´une table. Si aucune colonne n´est spécifiée, ils s´appliqueront par défaut à toutes les colonnes.

La clause ON déclare la table ou l´objet de base de données spécifique au niveau duquel les privilèges de l´utilisateur vont s´appliquer.

La clause TO indique l´utilisateur ou le rôle exact qui va recevoir une autorisation spécifique. Les privilèges peuvent aussi être accordés à PUBLIC; autrement dit, les utilisateurs (y compris ceux qui seront créés par la suite) disposeront tous du privilège spécifié. Une autorisation peut être accordée aux autres utilisateurs qui emploient WITH GRANT OPTION. Cette clause indique alors à la base de données que les utilisateurs qui ont reçu un privilège d´accès peuvent à leur tour accorder le même privilège d´accès à d´autres utilisateurs.

Suivant l´implémentation de base de données spécifique, les vues peuvent ou non disposer de privilèges d´accès indépendants à partir de leurs tables de base.

Microsoft SQL Server permet d´accorder les privilèges d´accès SELECT, INSERT, UPDATE, DELETE et REFERENCES à une table. Une liste de colonnes peut être identifiée pour les seules permissions d´accès SELECT et UPDATE. Par défaut, les colonnes reçoivent toutes les privilèges d´accès SELECT et UPDATE.

Seule la permission EXECUTE peut être accordée pour les procédures stockées, les procédures stockées étendues et les fonctions définies par l´utilisateur; un utilisateur doit disposer du privilège REFERENCES pour créer une contrainte FOREIGN KEY. Cette permission est également nécessaire pour créer une fonction ou une vue dépendant d´un objet doté de SCHEMABINDING.

La clause AS accorde des privilèges, comme s´il s´agissait d´un autre contexte de groupe ou de rôle. Puisque ni les groupes ni les rôles ne peuvent exécuter la commande GRANT, cette méthode permet d´accorder aisément des privilèges à un utilisateur qui n´appartient pas au groupe ou au rôle. Les privilèges peuvent uniquement être accordés au contexte de la base de données active.

D´abord, CREATE DATABASE et CREATE TABLE permettent d´accorder des permissions aux utilisateurs Emily et Sarah. Ensuite, diverses permissions sont accordées au groupe editors, sur la table titles. Les éditeurs peuvent alors accorder ces mêmes permission à d´autres utilisateurs:

MySQL propose des privilèges d´accès supplémentaires, qui concernent principalement la manipulation des objets dans une base de données. Comme pour les autres privilèges, l´attribution d´un privilège d´accès (par exemple, ALTER, CREATE, INDEX ou RELOAD) permet à l´utilisateur d´exécuter la commande correspondante. Bien que le privilège REFERENCES soit pris en charge, il n´a aucune fonctionnalité. La commande USAGE désactive les privilèges accordés à un utilisateur.

Les privilèges d´accès suivants s´appliquent aux tables: SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, GRANT, INDEX et ALTER. Les privilèges INSERT, UPDATE et SELECT peuvent s´appliquer au niveau des colonnes.

L´implémentation par MySQL de la clause ON offre des options intéressantes. Il est possible de définir des privilèges globaux, applicables à toutes les bases de données stockées sur le serveur, en spécifiant ON *.*. Pour définir des privilèges au niveau de la base de données, il convient de spécifier ON database_name.* ou ON * dans la base de données active. La longueur du nom des hôtes, des tables et des colonnes est limitée à 60 caractères.

MySQL permet d´accorder des droits à un utilisateur spécifique sur un hôte spécifique si le grantee_name respecte le format USER@HOST. L´inclusion de caractères génériques dans un grantee_name permet d´accorder le privilège d´accès à plusieurs utilisateurs en même temps. La longueur du grantee_name ne doit pas dépasser 16 caractères. Lorsque l´utilisateur est spécifié, l´inclusion de la clause IDENTIFIED BY permet de garantir la protection par mot de passe.

L´exemple suivant accorde des permissions à deux utilisateurs dotés de mots de passe:

Il saute aux yeux qu´Oracle propose une commande GRANT exhaustive. En fait, la syntaxe indiquée ne couvre pas la totalité des permutations de l´instruction. GRANT propose deux classes générales de privilèges: les privilèges objets (par exemple, le privilège permettant d´effectuer des sélections [SELECT] ou des suppressions [DELETE] dans une table spécifique) et les privilèges système (par exemple, CREATE CLUSTER ou DROP ANY TABLE).

Oracle ne permet pas de combiner les privilèges objets et système dans une même commande GRANT. Il est possible d´accorder plusieurs privilèges objets ou système à un même utilisateur ou rôle dans une commande GRANT, mais une commande GRANT ne permet pas d´accorder à la fois des privilèges objets et des privilèges système.

Une commande GRANT autorise la quasi-totalité des fonctions Oracle prises en charge. Il est possible d´accorder des privilèges non seulement pour des objets de base de données (tables et vues, par exemple) et des commandes système (CREATE ANY TABLE, par exemple), mais aussi pour des objets de schéma (DIRECTORY, JAVA SOURCE, et RESOURCE, entre autres).

L´option ANY permet d´exécuter une instruction donnée sur des objets d´un type spécifique appartenant à tout utilisateur du schéma. Vous trouverez une liste plus complète des privilèges système Oracle dans le Tableau 3.2.

PostgreSQL ne prend pas en charge les permissions de colonne ou la clause WITH GRANT OPTION. L´implémentation PostgreSQL de GRANT considère que la clause WITH GRANT OPTION est toujours activée. Tout utilisateur ayant reçu une permission peut accorder ce même privilège aux autres utilisateurs. PostgreSQL permet d´attribuer les permissions à un GROUPE, à condition qu´il s´agisse d´un nom_groupe existant valide.

Contrairement à d´autres éditeurs de base de données, PostgreSQL ne prend pas en charge GRANT dans les commandes système.

La prise en charge par PostgreSQL de l´instruction GRANT est fort simple:

L´instruction INSERT ajoute des lignes de données dans une table ou une vue. L´instruction INSERT permet d´entrer des enregistrements dans une table par l´une des méthodes suivantes:

1. La première méthode consiste à insérer des enregistrements sur la base des valeurs DEFAULT créées dans les colonnes de la table au moyen des instructions CREATE TABLE ou ALTER TABLE. (Oracle ne prend pas cette méthode en charge.)
2. La deuxième méthode, qui est aussi la plus courante, consiste à déclarer les valeurs exactes à insérer dans les colonnes de l´enregistrement.
3. La troisième méthode,qui permet d´entrer rapidement les enregistrements dans une table, consiste à insérer dans une table le jeu de résultats d´une instruction SELECT.

Pour utiliser l´instruction INSERT, vous devez commencer par déclarer la table (ou la vue) dans laquelle vous voulez insérer les données. Le mot-clé INTO est optionnel. Spécifiez les colonnes de la table qui recevront les données: placez-les entre parenthèses, en les séparant par une virgule, dans column_list. Si vous ignorez cette étape (ce qui est possible), les colonnes définies pour la table seront toutes utilisées.

La méthode DEFAULT VALUES est incompatible avec les méthodes list_of_values et SELECT_statement.

L´instruction INSERT . . . VALUES ajoute une ligne de données dans une table, sur la base des valeurs littérales qu´elle contient. Combinée à une instruction SELECT, l´instruction INSERT permet de remplir rapidement plusieurs lignes d´une table. Lorsque INSERT . . . SELECT est utilisée entre deux tables, il convient de s´assurer que ces dernières possèdent des structures et des types de données compatibles; il est cependant possible de compenser les incompatibilités entre les deux tables dans l´instruction SELECT. INSERT . . . SELECT est également prise en charge par PostgreSQL.

L´implémentation de la commande INSERT est différente dans Microsoft SQL Server, dans la mesure où elle autorise le mot-clé DEFAULT. Le mot-clé DEFAULT indique à l´instruction INSERT de créer un nouvel enregistrement sur la base de toutes les valeurs par défaut déclarées pour une table donnée.

La différence pour l´implémentation de cet éditeur réside dans le mot-clé EXECUTE. La clause EXECUTE indique à SQL Server de stocker le jeu de résultats renvoyé par une instruction Transact-SQL dynamique, une procédure stockée par le système, une procédure stockée par l´utilisateur, un RPC (Remote Procedure Call) ou une procédure stockée étendue d´une table locale.

Par exemple, l´instruction INSERT qui suit récupère le répertoire C:\temp et le stocke dans la table temporaire #ins_exec_container:

L´option LOW_PRIORITY indique à MySQL de reporter l´exécution de la commande INSERT jusqu´à ce que les autres clients aient fini de consulter la table. L´attente peut être assez longue. L´option DELAYED permet au client de poursuivre immédiatement, même si la commande INSERT n´est pas terminée. Le mot-clé IGNORE indique à MySQL de ne pas essayer d´insérer des enregistrements qui risqueraient de dupliquer la valeur d´une clé principale ou unique; dans ce cas, la commande INSERT échoue sans cette clause. La syntaxe SET column=value permet de déclarer les colonnes de la table et d´y insérer les valeurs.

L´implémentation dans Oracle de l´instruction INSERT permet d´insérer des données non seulement dans une table, une vue ou un instantané spécifique, mais également dans une partition ou une sous-partition particulière d´une table, au moyen des mots-clé PARTITION et SUBPARTITION keywords.

De nouvelles règles s´appliquent lorsque l´instruction INSERT est en corrélation avec une clause SELECT. Si la clause SELECT est associée à une clause VALUES, une seule ligne est insérée dans la table &8212; la première ligne renvoyée par la clause SELECT. Si la clause SELECT est utilisée dans la clause VALUES, les lignes renvoyées par la requête sont toutes insérées dans la table.

La clause RETURNING ne permet pas d´insérer les valeurs dans une table, mais dans des variables. Une correspondance bijective doit lier les expressions et les variables de la clause RETURNING. Les expressions renvoyées par la clause ne doivent pas nécessairement correspondre à celles mentionnées dans la clause VALUES. Par exemple, l´instruction INSERT qui suit place un enregistrement dans la table sales, mais place une valeur totalement différente dans une variable attachée:

La clause RETURNING renvoie hire_date même si hire_date ne compte pas parmi les valeurs indiquées dans la clause VALUES. (Dans le cas de notre exemple, nous pouvons supposer qu´une valeur par défaut a été définie pour la colonne hire_date.) La clause RETURNING ne permet pas de manipuler les types de données LONG. La clause RETURNING ne peut pas s´appliquer aux vues dotées de triggers INSTEAD OF.

De plus, la clause SELECT peut utiliser l´option WITH. La clause WITH READ ONLY spécifie que l´instruction INSERT ne peut pas servir à modifier le jeu de résultats récupéré par la clause SELECT. La clause WITH CHECK OPTION indique à Oracle d´interdire toute modification de données susceptible de générer des lignes qui ne soient pas incluses dans le jeu de résultats de la clause SELECT.

PostgreSQL prend en charge la norme SQL99 pour l´instruction INSERT. Reportez-vous à la section précédente pour plus de détails sur la syntaxe et l´utilisation de SQL99.

Dans cet exemple, une nouvelle ligne est insérée dans la table authors pour l´auteur Jessica Rabbit dans une base de données Microsoft SQL Server:

A chaque colonne est assignée une valeur littérale spécifique, à l´exception de la colonne phone, qui reçoit la valeur par défaut (attribuée dans le cadre de l´instruction CREATE TABLE ou ALTER TABLE) et city, qui a la valeur null.

L´exemple suivant illustre une instruction INSERT partielle sur une base de données Microsoft SQL Server contenant les mêmes données:

Pour charger des données de la table sales dans la table new_sales, il est possible d´utiliser INSERT . . . SELECT:

L´opérateur LIKE permet de spécifier des modèles de chaîne dans les instructions SELECT , INSERT, UPDATE et DELETE choisies pour la correspondance. Le modèle spécifié peut même inclure des caractères génériques spéciaux.

L´utilité de LIKE repose sur les opérateurs génériques qu´il prend en charge. LIKE renvoie la valeur booléenne TRUE lorsque la comparaison trouve au moins une valeur correspondante. La sensibilité à la casse par défaut du SGBD revêt une grande importance pour le comportement de LIKE. Par exemple, Microsoft SQL Server n´est pas par défaut sensible à la casse (mais vous pouvez le configurer dans ce sens). Ainsi, la requête:

va trouver les auteurs dont le nom de famille est stocké sous `larson' ou `lars', même si la recherche initiale portait sur `LARS%' (en majuscules). Oracle est sensible à la casse pour les caractères de modèle "%" et "_", et propose, sur la base d´opérateurs autres que LIKE, d´autres correspondances de modèles dans le cadre des expressions régulières. Les opérateurs génériques sont répertoriés dans le Tableau 3.3.

Dans le cadre des comparaisons de chaînes avec LIKE, tous les caractères du modèle revêtent une grande importance, y compris les espaces blancs en tête ou en queue .

La commande OPEN ouvre un curseur serveur créé au moyen d´une instruction DECLARE CURSOR. MySQL ne prend pas en charge les curseurs serveur de style ANSI.

cursor_name représente le nom du curseur créé au moyen de la commande DECLARE CURSOR.

En plus des curseurs serveur standard, Microsoft SQL Server permet de déclarer des curseurs globaux (au format OPEN GLOBAL cursor_name) qui seront référencés par plusieurs utilisateurs. De plus, Oracle permet de transmettre des paramètres directement au curseur à l´ouverture de ce dernier (au format OPEN cursor_name parameter1 [,...n]).

L´exemple suivant, qui repose sur Microsoft SQL Server, ouvre un curseur et relève toutes les lignes. Vous pouvez activer la même fonctionnalité dans Oracle et PostgreSQL sans la clause DEALLOCATE finale:

Un opérateur est un symbole servant à spécifier une action exécutée sur une ou plusieurs expressions. Les opérateurs sont surtout utilisés dans les instructions DELETE , INSERT, SELECT ou UPDATE, mais ils servent aussi dans une large mesure à la création d´objets de base de données (procédures stockées, fonctions, triggers et vues, notamment).

Les opérateurs entrent normalement dans les catégories logiques suivantes:

• Opérateurs arithmétiques
    Pris en charge par toutes les bases de données
• Opérateurs d'affectation
    Pris en charge par toutes les bases de données
• Opérateurs binaires
    Pris en charge par Microsoft SQL Server
• Opérateurs de comparaison
    Pris en charge par toutes les bases de données
• Opérateurs logiques
    Pris en charge par Oracle, Microsoft SQL Server et PostgreSQL
• Opérateurs unaires
    Pris en charge par Oracle

Les opérateurs arithmétiques effectuent des opérations mathématiques sur deux expressions de n´importe quel type de données dans la catégorie du type de données numérique. Voir Tableau 3.4 pour obtenir la liste des opérateurs arithmétiques.

Dans Oracle et SQL Server, les opérateurs + et – permettent également d´exécuter des opérations arithmétiques sur les valeurs de date.

Sauf dans Oracle, l´opérateur d'affectation (=) attribue la valeur à une variable ou à l´alias d´un en-tête de colonne. Dans Microsoft SQL Server, le mot-clé AS peut être attribué en tant qu´opérateur pour les alias d´en-têtes de table ou de colonne.

Dans Microsoft SQL Server, les opérateurs binaires servent de raccourcis pour l´exécution de manipulations par bit entre des expressions de deux nombres entiers (voir Tableau 3.5). Les types de données valides auxquels les opérateurs binaires peuvent accéder incluent binary, bit, int, smallint, tinyint et varbinary.

Les opérateurs de comparaison vérifient si deux expressions sont égales ou inégales. Le résultat d´une opération de comparaison est une valeur booléenne: TRUE, FALSE ou UNKNOWN. De plus, le comportement ANSI standard pour une opération de comparaison dans laquelle une ou plusieurs expressions ont la valeur NULL est NULL. Par exemple, l´expression 23 + NULL renvoie NULL, au même titre que l´expression Feb 23, 2002 + NULL. Voir Tableau 3.6 pour obtenir la liste des opérateurs de comparaison.

Les opérateurs de comparaison booléens sont surtout utilisés dans une clause WHERE pour filtrer les lignes qui respectent les critères de recherche. L´exemple Microsoft SQL Server qui suit utilise l´opération de comparaison supérieur ou égal à:

Les opérateurs logiques sont souvent utilisés dans une clause WHERE pour tester la véracité d´une condition spécifique. Les opérateurs logiques renvoient la valeur booléenne TRUE ou FALSE. Les opérateurs logiques sont également présentés dans le cadre de la rubrique SELECT. Les SGBDR ne gèrent pas systématiquement tous les opérateurs. Voir Tableau 3.7 pour obtenir la liste des opérateurs logiques.

Les opérateurs unaires exécutent une opération sur une seule expression de tout type de données de la catégorie numérique. Vous pouvez utiliser les opérateurs unaires pour les nombres entiers, mais les valeurs positives et négatives peuvent s´appliquer à tout type de données numérique (voir Tableau 3.8).

Il arrive que les expressions d´opérateur atteignent une grande complexité. Si une expression comporte plusieurs opérateurs, la priorité des opérateurs détermine l´ordre d´exécution des opérations. Cet ordre peut avoir une incidence considérable sur le résultat.

Les opérateurs respectent les niveaux de priorité suivants. Les opérateurs de niveau supérieur sont toujours évalués avant les opérateurs de niveau inférieur:

1. ( ) (expressions entre parenthèses)
2. +, -, ~ (opérateurs unaires)
3. *, /, % (opérateurs mathématiques)
4. +, - (opérateurs arithmétiques)
5. =, >, <, >=, <=, <>, !=, !>, !< (opérateurs de comparaison)
6. ^ (OR exclusif binaire), & (AND binaire), | (OR binaire)
7. NOT
8. AND
9. ALL, ANY, BETWEEN, IN, LIKE, OR, SOME
10. = (affectation variable)

L´évaluation des opérateurs s´effectue de gauche à droite lorsqu´ils possèdent le même niveau de priorité. Cependant, les parenthèses permettent d´outrepasser la priorité par défaut des opérateurs dans une expression. Les expressions mises entre parenthèses sont évaluées en premier, suivies des opérations en dehors de ces parenthèses.

Par exemple, les expressions suivantes dans une requêtre Oracle renvoient des résultats très différents:

Dans les expressions dotées de parenthèses imbriquées, l´évaluation commence par l´expression qui possède le niveau d´imbrication le plus élevé.

L´exemple qui suit contient des parenthèses imbriquées; l´expression 5 -3 est incluse dans le jeu de parenthèses qui possède le niveau d´imbrication le plus élevé. Cette expression renvoie la valeur 2. L´opérateur d´addition (+) ajoute ensuite ce résultat à 4, pour renvoyer la valeur 6. Enfin, la valeur 6 est multipliée par 2 pour renvoyer le résultat de l´expression, en l´occurrence 12:

L´instruction RETURN termine le traitement d´une fonction appelée par SQL (par opposition à une fonction appelée par un hôte) et renvoie, sous forme de valeur, le résultat de cette fonction.