Référence des commandes |
Ce chapitre représente l'essentiel de SQL in a Nutshell: il contient la liste des commandes SQL dans l'ordre alphabétique, chacune accompagnée d'exemples et d'explications détaillées. Un tableau général montre pour chaque commande ou fonction si elle est « prise en charge », « prise en charge avec des variations », « prise en charge avec des limites » ou « non prise en charge » dans chacun des quatre dialectes SQL évoqués dans ce livre: SQL Server, MySQL, Oracle et PostgreSQL. Après une courte description de la norme SQL99, chacune de ces applications est évoquée de façon concise mais détaillée, avec des examples et des échantillons de code.

ALTER PROCEDURE |
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.
Editeur | Commande
--- | ---
SQL Server | Prise en charge, avec des variations
MySQL | Non prise en charge
Oracle | Prise en charge, avec des variations
PostgreSQL | Non prise en charge
Syntaxe SQL99 et description
    ALTER PROCEDURE procedure_name {CASCADE | RESTRICT}
    [LANGUAGE | PARAMETER STYLE | <SQL data access> | <null clause behavior> | DYNAMIC RESULT SETS | NAME]
    [parameter datatype [,...n]
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.
Syntaxe Microsoft SQL Server et variations
    ALTER PROC[EDURE] procedure_name [;number]
    [ {@parameter datatype } [VARYING] [= default] [OUTPUT] ][,...n]
    [WITH { RECOMPILE | ENCRYPTION | RECOMPILE , ENCRYPTION } ]
    [FOR REPLICATION]
    AS
    T-SQL Block
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.
Syntaxe et variations dans Oracle
    ALTER PROCEDURE [user.]procedure_name COMPILE [DEBUG];
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.
Exemple
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:
    -- Une procédure stockée Microsoft SQL Server
    CREATE PROCEDURE get_next_nbr
      @next_nbr CHAR(22) OUTPUT
    AS
    BEGIN
     DECLARE @random_nbr INT
     SELECT @random_nbr = RAND( ) * 1000000

    SELECT @next_nbr =
     RIGHT('000000'+ CAST(ROUND(RAND(@random_nbr)*1000000,0))AS CHAR(6), 6) +
     RIGHT('0000'+ CAST(DATEPART (yy, GETDATE( ) ) AS CHAR(4)), 2) +
     RIGHT('000'+ CAST(DATEPART (dy, GETDATE( ) ) AS CHAR(3)), 3) +
     RIGHT('00' + CAST(DATEPART (hh, GETDATE( ) ) AS CHAR(2)), 2) +
     RIGHT('00' + CAST(DATEPART (mi, GETDATE( ) ) AS CHAR(2)), 2) +
     RIGHT('00' + CAST(DATEPART (ss, GETDATE( ) ) AS CHAR(2)), 2) +
     RIGHT('000'+ CAST(DATEPART (ms, GETDATE( ) ) AS CHAR(3)), 3)
    END
    GO

    ALTER PROCEDURE get_next_nbr
      @next_nbr INT OUTPUT
    AS
    BEGIN
     DECLARE @convert_to_nbr CHAR(22)
     DECLARE @random_nbr INT
     SELECT @random_nbr = RAND( ) * 1000000

    SELECT @convert_to_nbr =
     RIGHT('000000'+ CAST(ROUND(RAND(@random_nbr)*1000000,0))AS CHAR(6), 6) +
     RIGHT('0000'+ CAST(DATEPART (yy, GETDATE( ) ) AS CHAR(4)), 2) +
     RIGHT('000'+ CAST(DATEPART (dy, GETDATE( ) ) AS CHAR(3)), 3) +
     RIGHT('00' + CAST(DATEPART (hh, GETDATE( ) ) AS CHAR(2)), 2) +
     RIGHT('00' + CAST(DATEPART (mi, GETDATE( ) ) AS CHAR(2)), 2) +
     RIGHT('00' + CAST(DATEPART (ss, GETDATE( ) ) AS CHAR(2)), 2) +
     RIGHT('000'+ CAST(DATEPART (ms, GETDATE( ) ) AS CHAR(3)), 3)

    SELECT @next_nbr = CAST(@convert_to_nbr AS INT)

    END
    GO

ALTER TABLE |
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.
Editeur | Commande
--- | ---
SQL Server | Prise en charge, avec des variations
MySQL | Prise en charge, avec des limites
Oracle | Prise en charge, avec des variations
PostgreSQL | Prise en charge, avec des variations
Syntaxe SQL99 et description
    ALTER TABLE table_name
    [ADD [COLUMN] column_name datatype attributes]
    | [ALTER [COLUMN] column_name SET DEFAULT default_value]
    | [ALTER [COLUMN] column_name DROP DEFAULT]
    | [ALTER [COLUMN] column_name ADD SCOPE table_name
    | [ALTER [COLUMN] column_name DROP SCOPE {RESTRICT | CASCADE}]
    | [DROP [COLUMN] column_name {RESTRICT | CASCADE}]
    | [ADD table_constraint_name]
    | [DROP CONSTRAINT table_constraint_name {RESTRICT | CASCADE}]
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.
Syntaxe et variations dans Microsoft SQL Server
    ALTER TABLE table_name
    [ALTER COLUMN column_name new_data_type attributes {ADD | DROP}
      ROWGUIDCOL]
    | [ADD [COLUMN] column_name datatype attributes][,...n]
    | [WITH CHECK | WITH NOCHECK] ADD table_constraint][,...n]
    | [DROP { [ CONSTRAINT ] constraint_name | COLUMN column_name }] [,...n]
    | [{ CHECK | NOCHECK } CONSTRAINT { ALL | constraint_name [,...n] }]
    | [{ ENABLE | DISABLE } TRIGGER { ALL | trigger_name [,...n] }]
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.
Syntaxe et variations dans MySQL
    ALTER [IGNORE] TABLE table_name
    [ADD [COLUMN] column_name datatype attributes ]
      [FIRST | AFTER column_name]] [,...n]
    | [ADD INDEX [index_name] (index_col_name,...)] [,...n]
    | [ADD PRIMARY KEY (index_col_name,...)] [,...n]
    | [ADD UNIQUE [index_name] (index_col_name,...)] [,...n]
    | [ALTER [COLUMN] column_name {SET DEFAULT literal | DROP DEFAULT}] [,...n]
    | [CHANGE [COLUMN] old_col_name create_definition] [,...n]
    | [MODIFY [COLUMN] column_name datatype attributes] [,...n]
    | [DROP [COLUMN] column_name] [,...n]
    | [DROP PRIMARY KEY] [,...n]
    | [DROP INDEX index_name] [,...n]
    | [RENAME [AS] new_tbl_name] [,...n]
    | [table_options]
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:
    ALTER TABLE employee RENAME AS emp;
    ALTER TABLE employee CHANGE employee_ssn emp_ssn INTEGER;
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:
    ALTER TABLE mytable MODIFY mycolumn LONGTEXT
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.
Syntaxe et variations dans Oracle
    ALTER TABLE [owner_name.]table_name
    [ADD column_name datatype attributes]
    | [MODIFY {column_name datatype
      | column_constraint
      | physical_storage_attributes [LOGGING | NOLOGGING]
      | nested_table_attributes}]
    | [MODIFY CONSTRAINT {constraint_name {constraint_state}
      | drop_constraint_clause
      | drop_column_clause
      | [ALLOCATE | DEALLOCATE extent_clause]
      | [CACHE | NOCACHE]
      | [LOGGING | NOLOGGING]
      | [MONITORING | NOMONITORING] ]
    | [DROP {[COLUMN] column_name | constraint_name}]
    | [ALLOCATE EXTENT details]
    | [DEALLOCATE UNUSED details]
    | [RENAME TO new_table_name]
    | [OVERFLOW physical_storage_attributes]
    | [ADD OVERFLOW physical_storage_attributes]
    | [{ADD | DROP | MODIFY | MOVE | TRUNCATE | SPLIT | EXCHANGE | MODIFY}
      PARTITION partition_details]
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:
    ALTER TABLE titles
    ADD subtitle VARCHAR2(32) NULL
    CONSTRAINT unq_subtitle UNIQUE;
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:
    ALTER TABLE titles
    ADD (subtitles VARCHAR2(32) NULL,
      year_of_copyright INT,
      date_of_origin DATE);
Syntaxe et variations dans PostgreSQL
    ALTER TABLE table [*]
    [ADD [COLUMN] column_name datatype attributes]
    | [ALTER [COLUMN] column_name {SET DEFAULT value | DROP DEFAULT}]
    | [RENAME [COLUMN] column_name TO new_column_name]
    | [RENAME TO new_table_name]
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.

ALTER TRIGGER |
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.
Editeur | Commande
--- | ---
SQL Server | Prise en charge, avec des variations
MySQL | Non prise en charge
Oracle | Prise en charge, avec des variations
PostgreSQL | Non prise en charge
Syntaxe SQL99 et description
Il n'existe pour l'instant pas de norme SQL99 pour cette commande.
Syntaxe et variations dans Microsoft SQL Server
    ALTER TRIGGER trigger_name
    ON {table_name | view_name}
    [WITH ENCRYPTION]
    {FOR | AFTER | INSTEAD OF} {[DELETE] [,] [INSERT] [,] [UPDATE]}
    [WITH APPEND]
    [NOT FOR REPLICATION]
    AS
     T-SQL_block
    | [FOR { [INSERT] [,] [UPDATE] }
    [NOT FOR REPLICATION]
    AS

     { IF UPDATE(column) [{AND | OR} UPDATE(column)] [...n]
      |
      IF (COLUMNS_UPDATED( ) {bitwise_operator} updated_bitmask)
      { comparison_operator} column_bitmask [...n] }
      T-SQL_block ] } ]
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.
Syntaxe et variations dans Oracle
    ALTER TRIGGER [user.]trigger_name [ENABLE | DISABLE | COMPILE [DEBUG] ];
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.

ALTER VIEW |
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.
Editeur | Commande
--- | ---
SQL Server | Prise en charge, avec des variations
MySQL | Non prise en charge
Oracle | Prise en charge, avec des variations
PostgreSQL | Non prise en charge
Syntaxe SQL99 et description
Il n'existe pour l'instant pas de norme SQL99 pour cette commande.
Syntaxe et variations dans Microsoft SQL Server
    ALTER VIEW view_name [(column [,...n])]
    [WITH {ENCRYPTION | SCHEMABINDING | VIEW_METADATA]
    AS
    select_statement
    [WITH CHECK OPTION]
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.
Syntaxe et variations dans Oracle
    ALTER VIEW [user.]view_name COMPILE
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.
Exemple
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:
    CREATE VIEW california_authors
    AS
    SELECT au_lname, au_fname, city, state
    FROM authors
    WHERE state = 'CA'
    WITH CHECK OPTION
    GO

    ALTER VIEW california_authors
    AS
    SELECT au_fname, au_lname, address, city, state, zip
    FROM pubs..authors
    WHERE state = "CA"
    GO

CALL |
L'instruction CALL invoque une procédure stockée.
Editeur | Commande
--- | ---
SQL Server | Non prise en charge
MySQL | Non prise en charge
Oracle | Prise en charge
PostgreSQL | Prise en charge
Syntaxe SQL99 et description
    CALL procedure_name [(parameter [,...n] )]
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.
Syntaxe et variations dans Oracle
    CALL [schema.][{type_name | package_name}.]procedure_name@dblink
    [(parameter [,...n] )]
    [INTO:variable_name [INDICATOR:indicator_name] ]
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.
Exemple
Dans cet exemple, une procédure stockée simple est créée, puis invoquée indépendamment:
    CREATE PROCEDURE update_employee_salary
    (emp_id NUMBER, updated_salary NUMBER)
    IS
    BEGIN
     UPDATE employee SET salary = updated_salary WHERE employee_id =emp_id;
    END;

    CALL update_employee_salary(1517, 95000);

CASE |
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.
Editeur | Commande
--- | ---
SQL Server | Prise en charge
MySQL | Prise en charge
Oracle | Non prise en charge (la fonction DECODE offre une fonctionnalité équivalente; voir la documentation de l'éditeur)
PostgreSQL | Prise en charge
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.
Syntaxe SQL99 et description
    -- Opération de comparaison simple
    CASE input_value
    WHEN when_condition THEN resulting_value
    [...n]
    [ELSE else_result_value]
    END

    -- Opération conditionnelle logique
    CASE
    WHEN Boolean_condition THEN resulting_value
    [...n]
    [ELSE else_result_expression]
    END
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.
Exemples
Voici une comparaison simple où la fonction CASE modifie l'apparence de la colonne "contrat" pour en faciliter la compréhension:
    SELECT au_fname,
        au_lname,
        CASE contract
          WHEN 1 THEN 'Yes'
          ELSE 'No'
        END 'contract'
    FROM  authors
    WHERE  state = 'CA'
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:
    SELECT CASE
          WHEN ytd_sales IS NULL THEN 'Unknown'
          WHEN ytd_sales <=  200 THEN 'Not more than 200'
          WHEN ytd_sales <= 1000 THEN 'Between 201 and 1000'
          WHEN ytd_sales <= 5000 THEN 'Between 1001 and 5000'
          WHEN ytd_sales <= 10000 THEN 'Between 5001 and 10000'
          ELSE 'Over 10000'
        END 'YTD Sales',
        COUNT(*) 'Number of Titles'
    FROM  titles
    GROUP BY CASE
          WHEN ytd_sales IS NULL THEN 'Unknown'
          WHEN ytd_sales <=  200 THEN 'Not more than 200'
          WHEN ytd_sales <= 1000 THEN 'Between 201 and 1000'
          WHEN ytd_sales <= 5000 THEN 'Between 1001 and 5000'
          WHEN ytd_sales <= 10000 THEN 'Between 5001 and 10000'
          ELSE 'Over 10000'
         END
    ORDER BY MIN( ytd_sales )
Cette instruction donne les résultats suivants:
    YTD Sales       Number of Titles
    ---------------------- ----------------
    Unknown        2
    Not more than 200   1
    Between 201 and 1000 2
    Between 1001 and 5000 9
    Between 5001 and 10000 1
    Over 10000       3
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:
    UPDATE titles
    SET   price = price *
        CASE
          WHEN ytd_sales > 10000   THEN 0.95 -- 5% discount
          WHEN type = 'popular_comp'THEN 0.75 -- 25% discount
          ELSE 0.9               -- 10% discount
        END
    WHERE  pub_date IS NOT NULL
Trois opérations de mise à jour différentes sont donc exécutées simultanément, avec une seule instruction.

CAST |
La commande CAST convertit explicitement une expression d'un type de données à un autre.
Editeur | Commande
--- | ---
SQL Server | Prise en charge
MySQL | Non prise en charge
Oracle | Non prise en charge
PostgreSQL | Prise en charge
Syntaxe SQL99 et description
    CAST(expression AS data_type[(length)])
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.
Exemple
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:
    SELECT CAST(ytd_sales AS CHAR(5)) + "Copies sold of " + CAST(title AS
    VARCHAR(30))
    FROM titles
    WHERE ytd_sales IS NOT NULL
     AND ytd_sales > 10000
    ORDER BY ytd_sales DESC
On obtient ce qui suit:
    ---------------------------------------------------
    22246 Copies sold of The Gourmet Microwave
    18722 Copies sold of You Can Combat Computer Stress
    15096 Copies sold of Fifty Years in Buckingham Pala

CLOSE CURSOR |
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.
Editeur | Commande
--- | ---
SQL Server | Prise en charge
MySQL | Non prise en charge
Oracle | Prise en charge
PostgreSQL | Prise en charge
Syntaxe SQL99 et description
    CLOSE { cursor_name }
cursor_name représente le nom du curseur créé à l'aide de la commande DECLARE CURSOR.
Exemple
Cet exemple tiré de Microsoft SQL Server ouvre un curseur et extrait toutes les lignes:
    DECLARE employee_cursor CURSOR FOR
     SELECT lname, fname
     FROM pubs.dbo.authors
     WHERE lname LIKE 'K%'

    OPEN employee_cursor

    FETCH NEXT FROM employee_cursor

    WHILE @@FETCH_STATUS = 0
    BEGIN
     FETCH NEXT FROM Employee_Cursor
    END

    CLOSE employee_cursor

    DEALLOCATE employee_cursor
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.

COMMIT TRANSACTION |
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.
Editeur | Commande
--- | ---
SQL Server | Prise en charge, avec des variations
MySQL | Non prise en charge
Oracle | Prise en charge
PostgreSQL | Prise en charge
Syntaxe SQL99 et description
    COMMIT [WORK]
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:
    COMMIT [WORK] [AND [NO] CHAIN]
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.
Syntaxe et variations dans Microsoft SQL Server
    COMMIT [TRAN[SACTION] [transaction_name | @tran_name_variable] ]
    |
    COMMIT [WORK]
    GO
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.
Syntaxe et variations dans Oracle
    COMMIT [WORK];
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.
Syntaxe et variations dans PostgreSQL
    COMMIT [WORK | TRANSACTION];
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.
Exemple
    INSERT INTO sales VALUES('7896','JR3435','Oct 28
    1997',25,'Net
    60','BU7832');

    COMMIT WORK;

Opérateurs de Concaténation |
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 .
Editeur | Commande
--- | ---
SQL Server | Prise en charge, avec des variations
MySQL | Prise en charge, avec des variations
Oracle | Prise en charge
PostgreSQL | Prise en charge
Exemple et description
    SELECT lname || ', '|| fname FROM customers WHERE cust_id = 41;
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.

CONNECT |
L'instruction CONNECT établit une connexion au SGBD et à une base de données spécifique au sein du SGBD.
Editeur | Commande
--- | ---
SQL Server | Prise en charge, avec des limites
MySQL | Non prise en charge
Oracle | Prise en charge
PostgreSQL | Non prise en charge
Syntaxe SQL99 et description
    CONNECT [TO] DEFAULT
    | {[server_specification] [AS connection_name] [USER user_name ] }
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.
Syntaxe et variations dans Oracle
    CONN[ECT] [[username/password] [AS [SYSOPER | SYSDBA] ] ]
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.
Exemples
Pour se connecter avec un nom d'utilisateur spécifique, l'utilisateur (ou le programme automatisé) peut émettre la commande suivante:
    CONNECT TO USER pubs_admin
Si le SGBD exige qu'un nom soit utilisé pour permettre une connexion, on peut se servir de cette syntaxe:
    CONNECT TO USER pubs_admin AS pubs_administrative_session;
Microsoft SQL Server ne prend en charge CONNECT TO que lorsqu'elle est intégrée dans Embedded SQL (ESQL):
    EXEC SQL CONNECT TO new_york.pubs USER pubs_admin

CREATE DATABASE |
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.
Editeur | Commande
--- | ---
SQL Server | Prise en charge, avec des variations
MySQL | Prise en charge
Oracle | Prise en charge
PostgreSQL | Prise en charge, avec des variations
Syntaxe SQL99 et description
    CREATE database_name
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.
Syntaxe et variations dans Microsoft SQL Server
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:
    CREATE DATABASE database_name
    [ ON [PRIMARY]
    [ <file> [,...n] ]
    [, <file_group> [,...n] ]
    ]
    [ LOG ON { <file> [,...n]} ]
    [ FOR LOAD | FOR ATTACH ]
    GO
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.
Syntaxe et variations dans PostgreSQL et MySQL
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:
    CREATE DATABASE name [ WITH LOCATION = 'dbpath'];
Par exemple, pour créer la base de données sales_revenue dans le répertoire /home/teddy/private_db:
    CREATE DATABASE sales_revenue WITH LOCATION = '/home/teddy/private_db';
Syntaxe et variations dans Oracle
    CREATE DATABASE [database_name]
    [CONTROLFILE REUSE]
    [LOGFILE [GROUP1 integer] file1 integer [K | M] [,...n] [REUSE]]
      [MAXLOGFILES integer]
      [[MAXLOGMEMBERS] integer]
      [[MAXLOGHISTORY] integer]
    [DATAFILE file1 [AUTOEXTEND [,...n] [ON | OFF]]
       [NEXT integer [K | M]]
       [MAXSIZE [UNLIMITED | integer [K | M]]
      [MAXDATAFILES integer]
      [,...n]]
    [MAXINSTANCES integer]
    [MAXDATAFILES integer]
    [ARCHIVELOG | NOARCHIVELOG]
    {CHARACTER SET charset}
    {NATIONAL CHARACTER SET charset};
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:
    'file_path_and_name'SIZE bytes [K | M] REUSE
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:
    CREATE DATABASE publications
    LOGFILE ('/s01/oradata/loga01','/s01/oradata/loga02') SIZE 5M
    DATAFILE
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.

CREATE FUNCTION |
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.
Editeur | Commande
--- | ---
SQL Server | Prise en charge, avec des variations
MySQL | Prise en charge, avec des variations
Oracle | Prise en charge, avec des variations
PostgreSQL | Prise en charge, avec des variations
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.
Syntaxe SQL99 et description
    CREATE FUNCTION function_name
    [(parameter datatype attributes [,...n])]
    RETURNS datatype

     [LANGUAGE {ADA | C | FORTRAN | MUMPS | PASCAL | PLI | SQL}]
     [PARAMETER STYLE {SQL | GENERAL}]
     [SPECIFIC specific_name]
     [DETERMINISTIC | NOT DETERMINISTIC]
     [NO SQL | CONTAINS SQL | READS SQL DATA | MODIFIES SQL DATA]
     [RETURNS NULL ON NULL INPUT | CALL ON NULL INPUT]
     [STATIC DISPATCH]

    code block
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.
Syntaxe et variations dans Microsoft SQL Server
    CREATE FUNCTION [owner_name.]function_name
    ( [ {@parameter1 datatype [=default]} [,...n] ] )
    RETURNS {datatype | TABLE]
    [WITH {ENCRYPTION | SCHEMABINDING}]
    AS <Transact-SQL body>
    GO
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:
    CREATE FUNCTION metric_volume -- Input dimensions in centimeters.
      (@length decimal(4,1),
      @width decimal(4,1),
      @height decimal(4,1) )
    RETURNS decimal(12,3) -- Cubic Centimeters.
    AS BEGIN
       RETURN ( @length * @width * @height )
      END
    GO
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:
    SELECT project_name,
      metric_volume(construction_height,
       construction_length,
       construction_width)
    FROM housing_construction
    WHERE metric_volume(construction_height,
       construction_length,
       construction_width) >= 300000
    GO
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:
    SELECT co.order_id, co.order_price
    FROM  construction_orders AS co,
        fn_construction_projects('Cancelled') AS fcp
    WHERE co.construction_id = fcp.construction_id
    ORDER BY co.order_id
    GO
Syntaxe et variations dans MySQL
    CREATE [AGGREGATE] FUNCTION function_name
    RETURNS {STRING | REAL | INTEGER}
    SONAME shared_program_library_name;
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.
Syntaxe et variations dans Oracle
    CREATE [OR REPLACE] FUNCTION [owner_name.]function_name
    [(parameter1 [IN | OUT | IN OUT] [NOCOPY] datatype][,...n)]]
    RETURN datatype [DETERMINISTIC | AUTHID {CURRENT_USER | DEFINER} ]
     {IS | AS} {PL/SQL block | external program};
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:
    CREATE FUNCTION project_revenue (project IN varchar2)
    RETURN NUMBER
    AS
      proj_rev NUMBER(10,2);
    BEGIN
      SELECT SUM(DECODE(action,'COMPLETED',amount,0)) -
         SUM(DECODE(action,'STARTED',amount,0))  +
         SUM(DECODE(action,'PAYMENT',amount,0))
      INTO proj_rev
      FROM construction_actions
      WHERE project_name = project;
      RETURN (proj_rev);
    END;
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.
Syntaxe et variations dans PostgreSQL
    CREATE FUNCTION name ( [ parameter1 [,...n] ] )
    RETURNS datatype
    AS {definition | object_file, link_symbol}
    LANGUAGE {'C'| 'SQL'| 'PLPGSQL'| 'PLTCL'| 'PLTCLU'| 'PLPERL'
      | 'internal'}
    [WITH ISCACHABLE];
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:
    CREATE FUNCTION max_project_nbr
    RETURNS int4
    AS "SELECT MAX(project_ID) FROM housing_construction AS RESULT"
    LANGUAGE 'sql';
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.

CREATE INDEX |
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.
Editeur | Commande
--- | ---
SQL Server | Prise en charge, avec des variations
MySQL | Prise en charge, avec des variations
Oracle | Prise en charge, avec des variations
PostgreSQL | Prise en charge, avec des variations
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.
Syntaxe SQL99 et description
    CREATE INDEX index_name ON table_name (column_name [,...n])
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 »).
Syntaxe et variations dans Microsoft SQL Server
    CREATE [UNIQUE] [CLUSTERED | NONCLUSTERED] INDEX index_name
    ON {table | view} (column [ASC | DESC] [,...n])
    [WITH [PAD_INDEX]
      [[,] FILLFACTOR = fillfactor]
      [[,] IGNORE_DUP_KEY]
      [[,] DROP_EXISTING]
      [[,] STATISTICS_NORECOMPUTE] ]
    [ON filegroup]
    GO
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:
PAD_INDEX précise que tel espace devrait rester vierge sur chaque page de l'index, en fonction de la valeur de FILLFACTOR. 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. 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). 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é. 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. 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éé.
Syntaxe et variations dans MySQL
    CREATE [UNIQUE] INDEX index_name ON table_name (column_name(length) [,...n])
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.
Syntaxe et variations dans Oracle
    CREATE [UNIQUE | BITMAP] INDEX [owner_name.]index_name
    ON [schema.]{table ({column | expression} [ASC | DESC] [,...n])
      | CLUSTER cluster_name}
    [physical_attributes_clause | {LOGGING | NOLOGGING} |
     | [ONLINE] | [COMPUTE [STATISTICS] ]
     | {TABLESPACE tablespace_name | DEFAULT}
     | {COMPRESS int | NOCOMPRESS}
     | {NOSORT |REVERSE} ],...
     [GLOBAL PARTITION BY RANGE (column_list)
      (PARTITION [partition_name] VALUES LESS THAN (value_list)
      [physical_attributes_clause | {LOGGING | NOLOGGING} ] ,...n )
    | LOCAL [ (PARTITION [partition_name]
      [physical_attributes_clause | {LOGGING | NOLOGGING} ] ,...n ) ] ]
    [PARALLEL [int] | NOPARALLEL]
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 int
    | PCTUSED int
    | INITRANS int
    | MAXTRANS int
    | STORAGE storage...]
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.
Syntaxe et variations dans PostgreSQL
    CREATE [UNIQUE] INDEX index_name ON table
    [USING [BTREE | RTREE | HASH] ]
    (function_name (column [operator_class] [,...] ))
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.
Exemples
Cet exemple dans MySQL crée un simple index ascendant sur la colonne au_id de la table authors:
    CREATE INDEX au_id_ind
    ON authors (au_id);
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:
    CREATE TABLE housing_construction
      (project_number   INT NOT NULL,
      project_date     DATETIME NULL,
      project_name     VARCHAR(50)
        COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
      construction_color  NCHAR(20)
        COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
      construction_height DECIMAL(4, 1) NULL ,
      construction_length DECIMAL(4, 1) NULL ,
      construction_width  DECIMAL(4, 1) NULL ,
      construction_volume INT NULL
    GO

    CREATE UNIQUE CLUSTERED INDEX project_id_ind
    ON housing_construction(project_id)
    GO
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:
    CREATE UNIQUE INDEX project2_ind
    ON housing_construction(project_name, project_date)
    WITH PAD_INDEX, FILLFACTOR = 80
    GO
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:
    CREATE UNIQUE INDEX project2_ind
    ON housing_construction(project_name, project_date)
    STORAGE (INITIAL 10M NEXT 5M PCTINCREASE 0)
    TABLESPACE construction;
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é:
    CREATE UNIQUE CLUSTERED INDEX project_id_ind
    ON housing_construction(project_id)
    GLOBAL PARTITION BY RANGE (project_id)
      (PARTITION part1 VALUES LESS THAN ('K')
       TABLESPACE construction_part1_ndx_ts,
      PARTITION part2 VALUES LESS THAN (MAXVALUE)
       TABLESPACE construction_part2_ndx_ts);

CREATE PROCEDURE |
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.
Editeur | Commande
--- | ---
SQL Server | Prise en charge
MySQL | Non prise en charge (voir la commande CREATE FUNCTION)
Oracle | Prise en charge
PostgreSQL | Non prise en charge
Comme de nombreuses autres instructions CREATE, les éditeurs ont fait preuve d'une grande diversité dans l'implémentation de cette commande.
Syntaxe SQL99 et description
    CREATE PROCEDURE procedure_name
    [parameter data_type attributes ][,...n]
    AS
    code block
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.
Syntaxe et variations dans Microsoft SQL Server
    CREATE PROC[EDURE] procedure_name [;number]
    [{@parameter_name datatype} [VARYING] [= default] [OUTPUT]][,...n]
    [WITH {RECOMPILE | ENCRYPTION | RECOMPILE, ENCRYPTION}]
    [FOR REPLICATION]
    AS
    Transact-SQL_block
    GO
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.
Syntaxe et variations dans Oracle
    CREATE [OR REPLACE] PROCEDURE [owner_name.]procedure_name
    [(parameter1 [IN | OUT | IN OUT] [NOCOPY] datatype][,...n)]]
    [AUTHID {CURRENT_USER | DEFINER} ]
    {IS | AS} {PL/SQL block | LANGUAGE {java_spec | C_spec}};
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.
Exemple
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:
    -- Une procédure stockée Microsoft SQL Server
    CREATE PROCEDURE get_next_nbr
      @next_nbr CHAR(22) OUTPUT
    AS
    BEGIN
     DECLARE @random_nbr INT
     SELECT @random_nbr = RAND( ) * 1000000

    SELECT @next_nbr =
     RIGHT('000000'+ CAST(ROUND(RAND(@random_nbr)*1000000,0))AS CHAR(6), 6) +
     RIGHT('0000'+ CAST(DATEPART (yy, GETDATE( ) ) AS CHAR(4)), 2) +
     RIGHT('000'+ CAST(DATEPART (dy, GETDATE( ) ) AS CHAR(3)), 3) +
     RIGHT('00' + CAST(DATEPART (hh, GETDATE( ) ) AS CHAR(2)), 2) +
     RIGHT('00' + CAST(DATEPART (mi, GETDATE( ) ) AS CHAR(2)), 2) +
     RIGHT('00' + CAST(DATEPART (ss, GETDATE( ) ) AS CHAR(2)), 2) +
     RIGHT('000'+ CAST(DATEPART (ms, GETDATE( ) ) AS CHAR(3)), 3)
    END
    GO

CREATE ROLE |
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.
Editeur | Commande
--- | ---
SQL Server | Non prise en charge
MySQL | Non prise en charge
Oracle | Prise en charge, avec des variations
PostgreSQL | Non prise en charge
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.
Syntaxe SQL99 et description
    CREATE ROLE role_name [WITH ADMIN {CURRENT_USER | CURRENT_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.
Syntaxe et variations dans Oracle
    CREATE ROLE role_name [NOT IDENTIFIED | IDENTIFIED
      {BY password | EXTERNALLY | GLOBALLY}]
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.
Exemple
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:
    CREATE ROLE boss;

    GRANT ALL ON employee TO boss;
    GRANT CREATE SESSION, CREATE DATABASE LINK TO boss;

    ALTER ROLE boss IDENTIFIED BY le_grande_fromage;

    GRANT boss TO nancy, dale;

CREATE SCHEMA |
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).
Editeur | Commande
--- | ---
SQL Server | Prise en charge
MySQL | Non prise en charge
Oracle | Prise en charge, avec des variations
PostgreSQL | Non prise en charge
Syntaxe SQL99 et description
    CREATE SCHEMA [schema_name] [AUTHORIZATION owner_name]
    [DEFAULT CHARACTER SET char_set_name]
    [PATH schema_name [,...n] ]

      [ <create_table_statement1> [...n] ]
      [ <create_view_statement1> [...n] ]
      [ <grant statement1> [...n] ]
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.
Syntaxe Microsoft SQL Server et Oracle
    CREATE SCHEMA AUTHORIZATION owner_name
      [ <create_table_statement1> [...n] ]
      [ <create_view_statement1> [...n] ]
      [ <grant statement1> [...n] ]
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.
Exemple
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:
    CREATE SCHEMA AUTHORIZATION emily
      GRANT SELECT, INSERT ON view_1 TO sarah
      GRANT ALL ON table_1 TO sarah

      CREATE VIEW view_1 AS
       SELECT column_1, column_2
       FROM table_1
       ORDER BY column_2

      CREATE TABLE table_1(column_1 INT, column_2 CHAR(20));

CREATE TABLE |
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.
Editeur | Commande
--- | ---
SQL Server | Prise en charge, avec des variations
MySQL | Prise en charge, avec des variations
Oracle | Prise en charge, avec des variations
PostgreSQL | Prise en charge, avec des variations
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:
    CREATE TABLE table_name
      (
      column_name datatype[(length)] [NULL | NOT NULL],...n
      )
Voici un exemple simple:
    CREATE TABLE housing_construction
      (project_number   INT NOT NULL,
      project_date     DATETIME NOT NULL,
      project_name     VARCHAR(50) NOT NULL,
      construction_color  NCHAR(20) NULL,
      construction_height DECIMAL(4,1) NULL,
      construction_length DECIMAL(4,1) NULL,
      construction_width  DECIMAL(4,1) NULL,
      construction_volume INT NULL)
    GO
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.
Syntaxe SQL99 et description
    CREATE [GLOBAL TEMPORARY | LOCAL TEMPORARY] TABLE table_name
    [ON COMMIT {PRESERVE ROWS | DELETE ROWS}
    (column_name datatype attributes [,...n]
     | [LIKE table_name]
     | [table_constraint][,...n] ]
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.
Syntaxe et variations dans Microsoft SQL Server
    CREATE TABLE [database_name.[owner]. | owner.] table_name
    ({column_name datatype [ [DEFAULT default_value]
      | {IDENTITY [(seed,increment) [NOT FOR REPLICATION]]]
      [ROWGIDCOL] ]
      [NULL | NOT NULL]
      | [{PRIMARY KEY | UNIQUE}
        [CLUSTERED | NONCLUSTERED]
        [WITH FILLFACTOR = int] [ON {filegroup | DEFAULT}] ]
      | [[FOREIGN KEY]
        REFERENCES reference_table[(reference_column[,...n])]
        [ON DELETE {CASCADE | NO ACTION}]
        [ON UPDATE {CASCADE | NO ACTION}]
        [NOT FOR REPLICATION]
      | [CHECK [NOT FOR REPLICATION] (expression)
      | [COLLATE collation_name]
    |column_name AS computed_column_expression
    [,...n]
    |[table_constraint][,...n] )
    [ON {filegroup | DEFAULT} ]
    [TEXTIMAGE_ON {filegroup | DEFAULT} ]
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:
    CREATE TABLE people
      (people_id   CHAR(4)
        CONSTRAINT pk_dist_id PRIMARY KEY CLUSTERED
        CONSTRAINT ck_dist_id CHECK (dist_id LIKE '[A-Z][A-Z][A-Z][A-Z]'),
       people_name  VARCHAR(40) NULL,
       people_addr1 VARCHAR(40) NULL,
       people_addr2 VARCHAR(40) NULL,
       city     VARCHAR(20) NULL,
       state     CHAR(2)   NULL
        CONSTRAINT def_st DEFAULT ("CA")
        CONSTRAINT chk_st REFERENCES states(state_ID),
       zip      CHAR(5)   NULL
        CONSTRAINT ck_dist_zip
        CHECK(zip LIKE '[0-9][0-9][0-9][0-9][0-9]'),
       phone     CHAR(12)  NULL,
       sales_rep   empid    NOT NULL DEFAULT USER)
    GO
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:
    -- Création d'une contrainte de colonne
    CREATE TABLE favorite_books
      (isbn     CHAR(100)  PRIMARY KEY NONCLUSTERED,
       book_name   VARCHAR(40) UNIQUE,
       category   VARCHAR(40) NULL,
       subcategory  VARCHAR(40) NULL,
       pub_date   DATETIME   NOT NULL,
       purchase_date DATETIME   NOT NULL)
    GO

    -- Création d'une contrainte de table
    CREATE TABLE favorite_books
      (isbn     CHAR(100)  NOT NULL,
       book_name   VARCHAR(40) NOT NULL,
       category   VARCHAR(40) NULL,
       subcategory  VARCHAR(40) NULL,
       pub_date   DATETIME   NOT NULL,
       purchase_date DATETIME   NOT NULL,
        CONSTRAINT pk_book_id  PRIMARY KEY NONCLUSTERED (isbn)
          WITH FILLFACTOR=70,
        CONSTRAINT unq_book   UNIQUE CLUSTERED (book_name,pub_date))
    GO
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.
Syntaxe et variations dans MySQL
    CREATE [TEMPORARY] TABLE [IF NOT EXISTS] table_name
    (column_name datatype [NULL | NOT NULL] [DEFAULT default_value]
      [AUTO_INCREMENT]
      [PRIMARY KEY] [reference_definition] |
      [CHECK (expression) |
      [INDEX [index_name] index_col_name1[(length)],...n)] |
      [UNIQUE [INDEX] [index_name] (index_col_name1,...n)] |
      [CONSTRAINT symbol] FOREIGN KEY index_name (index_col_name1,...n)
       [REFERENCES table_name [(index_col_name,...)]
       [MATCH FULL | MATCH PARTIAL]
       [ON DELETE {RESTRICT | CASCADE | SET NULL | NO ACTION | SET DEFAULT}]
       [ON UPDATE {RESTRICT | CASCADE | SET NULL | NO ACTION | SET DEFAULT}])
    {[TYPE = {ISAM | MYISAM | HEAP} |
      AUTO_INCREMENT = int |
      AVG_ROW_LENGTH = int |
      CHECKSUM = {0 | 1} |
      COMMENT = "string" |
      DELAY_KEY_WRITE = {0 | 1} |
      MAX_ROWS = int |
      MIN_ROWS = int |
      PACK_KEYS = {0 | 1} |
      PASSWORD = "string" |
      ROW_FORMAT= { default | dynamic | static | compressed }] }
    [[IGNORE | REPLACE] SELECT_statement]
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:
    CREATE TABLE test_example
     (column_a INT NOT NULL AUTO_INCREMENT,
     PRIMARY KEY(column_a),
     INDEX(column_b))
    TYPE=HEAP
    SELECT column_b,column_c FROM samples;
Ceci crée une table heap avec trois colonnes: column_a, column_b et column_c.
Syntaxe et variations dans Oracle
    CREATE [GLOBAL TEMPORARY] TABLE [schema.]table_name
    ( column_name datatype [DEFAULT] {column_constraint [...]} [,...n]
    | table_constraint [,...n] } )
    [ON COMMIT {DELETE | PRESERVE} ROWS]
    ( physical_characteristics )
    ( table_characteristics )
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:
    CREATE GLOBAL TEMPORARY TABLE shipping_schedule
     (ship_date DATE,
      receipt_date DATE,
      received_by VARCHAR2(30),
      amt NUMBER)
    ON COMMIT PRESERVE ROWS;
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:
    -- physical_characteristics
    {[{[physical_attributes]
    | TABLESPACE tablespace_name
    | {LOGGING | NOLOGGING} }]
    | {ORGANIZATION {HEAP [{[physical_attributes]
      | TABLESPACE tablespace_name
      | {LOGGING | NOLOGGING} }]
    | INDEX indexed_table_clause)}
    | CLUSTER cluster_name (column [,...n]) }
    [special_storage_clause]
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):
    -- physical_attributes
    [{PCTFREE int | PCTUSED int | INITRANS int | MAXTRANS int | storage_
      clause}]
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:
    -- storage_clause
    STORAGE ( [ {INITIAL int [K | M]
          | NEXT int [K | M]
          | MINEXTENTS int
          | MAXEXTENTS {int | UNLIMITED}
          | PCTINCREASE int
          | FREELISTS int
          | FREELIST GROUPS int
          | OPTIMAL [{int [K | M] | NULL}]
          | BUFFER_POOL {KEEP | RECYCLE | DEFAULT} ] [...] )
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:
    CREATE TABLE book_sales
     (qty NUMBER,
      period_end_date DATE,
      period_nbr NUMBER)
    TABLESPACE sales
    STORAGE (INITIAL 8M NEXT 8M MINEXTENTS 1 MAXEXTENTS 8);
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:
    {LOB { (LOB_item [,n]) STORE AS {ENABLE | DISABLE} STORAGE IN ROW
       | (LOB_item) STORE AS
          {LOB_segment_name ({ENABLE | DISABLE} STORAGE IN ROW)
          | LOB_segment_name
          | ({ENABLE | DISABLE} STORAGE IN ROW)}
     | VARRAY varray_item STORE AS
     | NESTED TABLE nested_item STORE AS storage_table
       [(physical_characteristics)]
       [RETURN AS {LOCATOR | VALUE}] }
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:
    CREATE TABLE large_objects
     (pretty_picture BLOB,
      interesting_text CLOB)
    STORAGE (INITIAL 256M NEXT 256M)
    LOG (pretty_picture, interesting_text)
      STORE AS (TABLESPACE large_object_segment
       STORAGE (INITIAL 512M NEXT 512M)
       NOCACHE LOGGING);
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:
    CREATE TYPE prop_nested_tbl AS TABLE OF props_nt;

    CREATE TABLE proposal_types
      (proposal_category VARCHAR2(50),
      proposals     PROPS_NT)
    NESTED TABLE props_nt STORE AS props_nt_table;
Oracle permet de définir toutes sortes de caractéristiques pour une table donnée. En voici quelques unes:
    -- table_characteristics
    { PARTITION characteristics }
    [CACHE | NOCACHE] [MONITORING | NOMONITORING]
    [{NOPARALLEL | PARALLEL [int] }]
    [{ENABLE | DISABLE} [VALIDATE | NOVALIDATE]
     {UNIQUE (column [,...n] )
     | PRIMARY KEY
     | CONSTRAINT constraint_name}
    [index_clause]
    [EXCEPTION INTO [schema.]table_name]
    [CASCADE] ]
    [AS select_statement]
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:
    DISABLE | ENABLE {{UNIQUE(column[,...n] |
      PRIMARY KEY |
      CONSTRAINT constraint_name}
       [CASCADE]}
       [EXCEPTIONS INTO [owner.]table_name]
       [USING INDEX [INITRANS int][MAXTRANS int]
         [TABLESPACE tablespace_name][storage_characteristics]
         [PCTFREE int] |
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.
Syntaxe et variations dans PostgreSQL
    CREATE [TEMPORARY | TEMP] TABLE table
    (column_name datatype [NULL | NOT NULL] [DEFAULT value]
     |[UNIQUE]
     | [PRIMARY KEY (column[,...n])]
      | [CHECK (expression) ]
      | REFERENCES reference_table (reference_column)
        [MATCH {FULL | PARTIAL | default}]
        [ON DELETE {CASCADE | NO ACTION | RESTRICT | SET NULL | SET
          DEFAULT}]
        [ON UPDATE {CASCADE | NO ACTION | RESTRICT | SET NULL | SET
          DEFAULT}]
        [[NOT] DEFERRABLE] [INITIALLY {DEFERRED | IMMEDIATE}] } [,...n]
    |[table_constraint][,...n]
    [INHERITS (inherited_table [,...n])]

    | [ON COMMIT {DELETE | PRESERVE} ROWS]

    | AS SELECT_statement
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:
    [FOREIGN KEY (column[,...n]) REFERENCES...]
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.
Exemples
Le code ci-dessous ajoute une clé étrangère à la table de l'exemple:
    -- Création d'une contrainte de colonne
    CREATE TABLE favorite_books
      (isbn     CHAR(100)  PRIMARY KEY NONCLUSTERED,
      book_name   VARCHAR(40) UNIQUE,
      category   VARCHAR(40) NULL,
      subcategory  VARCHAR(40) NULL,
      pub_date   DATETIME   NOT NULL,
      purchase_date DATETIME   NOT NULL,
       CONSTRAINT fk_categories FOREIGN KEY (category)
         REFERENCES category(cat_name));
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:
    ...
    CONSTRAINT fk_categories FOREIGN KEY (category, subcategory)
         REFERENCES category(cat_name, subcat_name));
Voici deux exemples complets supplémentaires, tirés de la base de données pubs (jobs et employee):
    -- Pour une base de données Microsoft SQL Server
    CREATE TABLE jobs
      (job_id SMALLINT IDENTITY(1,1) PRIMARY KEY CLUSTERED,
      job_desc VARCHAR(50) NOT NULL DEFAULT 'New Position',
      min_lvl TINYINT NOT NULL CHECK (min_lvl >= 10),
      max_lvl TINYINT NOT NULL CHECK (max_lvl <= 250))

    -- Pour une base de données MySQL
    CREATE TABLE employee
      (emp_id INT AUTO_INCREMENT CONSTRAINT PK_emp_id PRIMARY KEY,
      fname VARCHAR(20) NOT NULL,
      minit CHAR(1) NULL,
      lname VARCHAR(30) NOT NULL,
      job_id SMALLINT NOT NULL DEFAULT 1
       REFERENCES jobs(job_id),
      job_lvl TINYINT DEFAULT 10,
      pub_id CHAR(4) NOT NULL DEFAULT ('9952')
       REFERENCES publishers(pub_id),
      hire_date DATETIME NOT NULL DEFAULT (CURRENT_DATE( ));

    CREATE TABLE publishers
      (pub_id char(4) NOT NULL
       CONSTRAINT UPKCL_pubind PRIMARY KEY CLUSTERED
       CHECK (pub_id IN ('1389', '0736', '0877', '1622', '1756')
       OR pub_id LIKE '99[0-9][0-9]'),
      pub_name varchar(40) NULL,
      city varchar(20) NULL,
      state char(2) NULL,
      country varchar(30) NULL DEFAULT('USA'))
L'exemple qui suit est une instruction CREATE TABLE Oracle dotée de nombreuses propriétés de stockage:
    CREATE TABLE classical_music_cds
      (music_id    INT,
      composition   VARCHAR2(50),
      composer     VARCHAR2(50),
      performer    VARCHAR2(50),
      performance_date DATE DEFAULT SYSDATE,
      duration     INT,
      cd_name     VARCHAR2(100),
    CONSTRAINT pk_class_cds PRIMARY KEY (music_id)
      USING INDEX TABLESPACE index_ts
      STORAGE (INITIAL 100K NEXT 20K),
    CONSTRAINT uq_class_cds UNIQUE (composition, performer, performance_date)
      USING INDEX TABLESPACE index_ts
      STORAGE (INITIAL 100K NEXT 20K))
    TABLESPACE tabledata_ts;

CREATE TRIGGER |
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.
Editeur | Commande
--- | ---
SQL Server | Prise en charge, avec des variations
MySQL | Non prise en charge
Oracle | Prise en charge, avec des variations
PostgreSQL | Prise en charge, avec des variations
Syntaxe SQL99 et description
    CREATE TRIGGER trigger_name
    {BEFORE | AFTER} {[DELETE] | [INSERT] | [UPDATE] [OF column [,...n]}
    ON table_name
    [REFERENCING {OLD [ROW] [AS] old_name | NEW [ROW] [AS] new_name
     OLD TABLE [AS] old_name | NEW TABLE [AS] new_name}]
    [FOR EACH { ROW | STATEMENT }]
    [WHEN (conditions)]
    code block
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.
Syntaxe et variations dans Microsoft SQL Server
    CREATE TRIGGER trigger_name
    ON {table_name | view_name}
    [WITH ENCRYPTION]
    {FOR | AFTER | INSTEAD OF} {[DELETE] [,] [INSERT] [,] [UPDATE]}
    [WITH APPEND]
    [NOT FOR REPLICATION]
    AS
     {
     T-SQL_block
     |
     { IF UPDATE(column) [{AND | OR} UPDATE(column)] [...n]
      |
      IF (COLUMNS_UPDATED( ) {bitwise_operator} updated_bitmask)
      { comparison_operator} column_bitmask [...n] }
      T-SQL_block [...n]
      }
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.
Syntaxe et variations dans Oracle
    CREATE [OR REPLACE] TRIGGER [owner.]trigger_name
    {BEFORE | AFTER | INSTEAD OF}
    {[DELETE] [OR] [INSERT] [OR] [UPDATE [OF column [,...n] ]] [...n]}
    ON {table_name | view_name}
    [REFERENCING {OLD [AS] old_name | NEW [AS] new_name}]
    [FOR EACH { ROW | STATEMENT }]
    [WHEN (conditions)]
    PL/SQL block
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.
Syntaxe et variations dans PostgreSQL
    CREATE TRIGGER trigger_name
    { BEFORE | AFTER }
    { {[DELETE] [OR | ,] [INSERT] [OR | ,] [UPDATE]} [OR...] }
    ON table_name
    FOR EACH { ROW | STATEMENT }
    EXECUTE PROCEDURE function_name (parameters)
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.
Exemples
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:
    CREATE TRIGGER if_dist_exists
    BEFORE INSERT OR UPDATE ON sales
    FOR EACH ROW
    EXECUTE PROCEDURE check_primary_key ('did', 'distributors', 'did');
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é:
    CREATE TRIGGER if_emp_changes
    BEFORE DELETE OR UPDATE ON employee
    FOR EACH ROW
    WHEN (new.emp_salary <> old.emp_salary)
    BEGIN
     INSERT INTO employee_audit
     VALUES ('old',:old.emp_id,:old.emp_salary,:old.emp_ssn);
    END;
L'exemple ci-dessous produit un trigger d'insertion et de mise à jour dans Oracle qui utilise les clauses IF INSERTED THEN:
    CREATE TRIGGER if_emp_changes
    BEFORE DELETE OR UPDATE ON employee
    FOR EACH ROW
    BEGIN
     IF DELETING THEN
      INSERT INTO employee_audit
      VALUES ('DELETED',:old.emp_id,:old.emp_salary,:old.emp_ssn);
     ELSE
      INSERT INTO employee_audit
      VALUES ('UPDATED',:old.emp_id,:new.emp_salary,:old.emp_ssn);
     END IF;
    END;
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:
    CREATE TRIGGER if_emp_is_contractor
    INSTEAD OF INSERT ON employee
    BEGIN
     INSERT INTO contractor
     SELECT * FROM inserted WHERE status = 'CON'

     INSERT INTO employee
     SELECT * FROM inserted WHERE status = 'FTE'
    END
    GO

CREATE VIEW |
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.
Editeur | Commande
--- | ---
SQL Server | Prise en charge, avec des variations
MySQL | Non prise en charge
Oracle | Prise en charge, avec des variations
PostgreSQL | Prise en charge, avec des variations
Les vues peuvent même être créées à partir d'autre vues, mais cette pratique n'est pas recommandée.
Syntaxe SQL99 et description
    CREATE VIEW view_name [(column list)]
    AS
    (SELECT_statement
    [WITH [CASCADED | LOCAL] CHECK OPTION] )
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:
L'instruction SELECT dont provient la vue est basée sur une table. La vue ne comporte pas d'opérateurs UNION, MINUS ou INTERSECT. L'instruction SELECT dont elle provient ne contient pas de clauses GROUP BY ou HAVING. L'instruction SELECT dont elle provient ne contient aucune référence à des pseudo-colonnes comme ROWNUM ou ROWGUIDCOL. L'instruction SELECT dont elle provient ne contient aucune fonction de groupe. L'instruction SELECT dont elle provient ne contient pas la clause DISTINCT.
Syntaxe et variations dans Microsoft SQL Server
    CREATE [owner_name.]VIEW view_name [(column [,...n])]
    [WITH {ENCRYPTION | SCHEMABINDING | VIEW_METADATA} [,...n]]
    AS
    select_statement
    [WITH CHECK OPTION]
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.
Syntaxe et variations dans Oracle
    CREATE [OR REPLACE] [FORCE | NO FORCE] VIEW [owner_name.]view_name
     [(column [,...n])]
    AS
    SELECT_statement
    [WITH [READ ONLY | CHECK OPTION [CONSTRAINT constraint_name] ] ]
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.
Syntaxe et variations dans PostgreSQL
    CREATE VIEW view_name AS SELECT_statement
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.
Exemples
La vue la plus simple est basée sur l'intégralité du contenu d'une seule table:
    CREATE VIEW employees
    AS
    SELECT *
    FROM employee_tbl;
Cet exemple montre une vue intitulée california_authors qui ne permet que les modifications appliquées aux auteurs vivant en Californie:
    CREATE VIEW california_authors
    AS
    SELECT au_lname, au_fname, city, state
    FROM authors
    WHERE state = 'CA'
    WITH CHECK OPTION
    GO

DECLARE CURSOR |
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:
Déclarer le curseur (DECLARE). Ouvrir le curseur (OPEN). extraire les lignes du curseur (FETCH). 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.
Editeur | Commande
--- | ---
SQL Server | Prise en charge
MySQL | Non prise en charge
Oracle | Prise en charge
PostgreSQL | Prise en charge
Syntaxe SQL99 et description
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.
Syntaxe dans Microsoft SQL Server
    DECLARE cursor_name [INSENSITIVE] [SCROLL] CURSOR
    FOR select_statement
    [FOR {READ ONLY | UPDATE [OF column_name [,...n]]}]
Syntaxe dans Oracle
    DECLARE CURSOR cursor_name [parameter1 datatype1 [,...parameterN datatypeN]
    IS select_statement
    [FOR UPDATE [OF column_name [,...n]]}]
Syntaxe dans PostgreSQL
    DECLARE cursor_name [BINARY] [INSENSITIVE] [SCROLL] CURSOR
    FOR select_statement
    [FOR {READ ONLY | UPDATE [OF column_name [,...n]]}]
Syntaxe et variations dans Microsoft SQL Server
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:
    DECLARE cursor_name CURSOR
    [LOCAL | GLOBAL] [FORWARD_ONLY | SCROLL]
    [STATIC | KEYSET | DYNAMIC | FAST_FORWARD]
    [READ_ONLY | SCROLL_LOCKS | OPTIMISTIC]
    [TYPE_WARNING]
    FOR select_statement
    [FOR UPDATE [OF column_name [,...n]]]
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).
Exemples
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):
    DECLARE @publisher_name VARCHAR(20)

    DECLARE pub_cursor CURSOR
    FOR SELECT pub_name FROM publishers
      WHERE country <> 'USA'

    OPEN pub_cursor
    FETCH NEXT FROM pub_cursor INTO @publisher_name
    WHILE @@FETCH_STATUS = 0
    BEGIN
      INSERT INTO foreign_publishers VALUES(@publisher_name)
    END

    CLOSE pub_cursor
    DEALLOCATE pub_cursor
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é:
    DECLARE
      new_price NUMBER(10,2);
      CURSOR title_price_cursor IS
       SELECT title, price
       FROM titles
       WHERE price IS NOT NULL;
      title_price_val title_price_cursor%ROWTYPE;
    BEGIN
      OPEN title_price_cursor;
      FETCH title_price_cursor INTO title_price_val;
      new_price:= "title_price_val.price" * 1.25
      INSERT INTO new_title_price VALUES (title_price_val.title, new_price)
      CLOSE title_price_cursor;
    END;
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.

DELETE |
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.
Editeur | Commande
--- | ---
SQL Server | Prise en charge, avec des variations
MySQL | Prise en charge, avec des variations
Oracle | Prise en charge
PostgreSQL | Prise en charge
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.
Syntaxe SQL99 et description
    DELETE [FROM] [owner.]table_name [WHERE clause]
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.
Syntaxe et variations dans Microsoft SQL Server
    DELETE [FROM] [owner.] {table_name | view_name}
    [WITH (query_hint[,...n]]
    [FROM table_source[,...n]]
    [WHERE clause | [CURRENT OF [GLOBAL] cursor_name]]
    [OPTION (query_hint[,...n])]
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.
Syntaxe et variations dans MySQL
    DELETE [LOW_PRIORITY] FROM table_name [WHERE clause] [LIMIT rows]
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.
Syntaxe et variations dans Oracle
    DELETE FROM [schema.]{table_name | view_name | snapshot_name}
      {PARTITION (partition_name) | SUBPARTITION (subpartition_name)} |
    [WHERE clause]
    [subquery WITH {READ ONLY | CHECK OPTION [CONSTRAINT constraint_name]} ]
    [RETURNING expression[,...] INTO variable[,...]
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.
Syntaxe et variations dans PostgreSQL
    DELETE FROM [ONLY] table
    [WHERE {clause | CURRENT OF cursor_name}]
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.
Exemples
Pour effacer tous les enregistrements de la table titles:
    DELETE titles
Pour effacer tous les enregistrements dont le nom de famille commence par « Mc » de la table authors:
    DELETE FROM authors
    WHERE au_lname LIKE 'Mc%'
Pour effacer tous les titres dotés d'un code d'identification obsolète:
    DELETE titles WHERE title_id >= 40
Pour effacer tous les titres qui ne se vendent pas:
    DELETE titles WHERE ytd_sales IS NULL
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):
    DELETE FROM titleauthor
    WHERE title_id IN
     (SELECT title_id
     FROM titles
     WHERE title LIKE '%computers%')

DISCONNECT |
L´instruction DISCONNECT met fin à une connexion au SGBD.
Editeur | Commande
--- | ---
SQL Server | Prise en charge, avec des limites
MySQL | Non prise en charge
Oracle | Prise en charge, avec des variations
PostgreSQL | Non prise en charge
Syntaxe SQL99 et description
    DISCONNECT {CURRENT | ALL | connection_name}
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.
Syntaxe et variations dans Microsoft SQL Server
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.
Syntaxe et variations dans Oracle
    DISC[ONNECT]
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
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.
Exemples
Pour mettre fin à la connexion en cours à un serveur Oracle:
    DISCONNECT;
Microsoft SQL Server prend uniquement en charge la commande DISCONNECT dans les programmes ESQL:
    EXEC SQL DISCONNECT new_york;

DROP DATABASE |
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.
Editeur | Commande
--- | ---
SQL Server | Prise en charge
MySQL | Prise en charge
Oracle | Non prise en charge
PostgreSQL | Prise en charge
Syntaxe SQL99 et description
    DROP DATABASE database_name
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.
Syntaxe et variations dans Microsoft SQL Server
    DROP DATABASE database_name [,...n]
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.
Syntaxe et variations dans MySQL et PostgreSQL
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.
Syntaxe et variations dans Oracle
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.

DROP FUNCTION |
Cette commande élimine de la base de données active une fonction définie par l´utilisateur.
Editeur | Commande
--- | ---
SQL Server | Prise en charge, avec des variations
MySQL | Prise en charge, avec des variations
Oracle | Prise en charge, avec des variations
PostgreSQL | Prise en charge, avec des variations
Syntaxe SQL99 et description
    DROP FUNCTION function_name {RESTRICT | CASCADE}
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 !
Syntaxe et variations dans Microsoft SQL Server
    DROP FUNCTION [owner_name.]function_name [,...n]
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.
Syntaxe et variations dans MySQL
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.
Syntaxe et variations dans Oracle
    DROP FUNCTION [owner_name.]function_name
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.
Syntaxe et variations dans PostgreSQL
    DROP FUNCTION name ( [ type [,...n] ] )
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.

DROP INDEX |
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.
Editeur | Commande
--- | ---
SQL Server | Prise en charge, avec des variations
MySQL | Prise en charge, avec des variations
Oracle | Prise en charge, avec des variations
PostgreSQL | Prise en charge, avec des variations
Syntaxe SQL99 et description
    DROP INDEX table_name.index_name
PostgreSQL respecte la norme SQL99, avec certaines variations.
Syntaxe et variations dans Microsoft SQL Server
    DROP INDEX {table_name | view_name}.index_name [,...n]
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.
Syntaxe et variations dans MySQL
    DROP INDEX table_name.index_name [,...n]
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.
Syntaxe et variations dans Oracle
    DROP INDEX [owner_name.]index_name
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.

DROP PROCEDURE |
Cette commande permet de supprimer une procédure stockée dans la base de données utilisateur active.
Editeur | Commande
--- | ---
SQL Server | Prise en charge
MySQL | Non prise en charge
Oracle | Prise en charge
PostgreSQL | Non prise en charge
Syntaxe SQL99 et description
    DROP PROCEDURE procedure_name {RESTRICT | CASCADE}
Cette commande est pratiquement similaire à DROP FUNCTION, sauf qu´elle s´applique aux procédures stockées, et non aux fonctions.
Syntaxe et variations dans Microsoft SQL Server
    DROP PROCEDURE [owner_name.]procedure_name [,...n]
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é.
Syntaxe et variations dans Oracle
    DROP PROCEDURE [owner_name.]procedure_name
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.

DROP ROLE |
Cette commande permet de supprimer un ensemble nommé de privilèges utilisateur dans la base de données utilisateur active.
Editeur | Commande
--- | ---
SQL Server | Non prise en charge
MySQL | Non prise en charge
Oracle | Prise en charge, avec des variations
PostgreSQL | Non prise en charge
Syntaxe SQL99 et description
    DROP ROLE role_name
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.
Syntaxe Oracle
    DROP ROLE [owner_name.]role_name;
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.

DROP TABLE |
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.
Editeur | Commande
--- | ---
SQL Server | Prise en charge, avec des variations
MySQL | Prise en charge, avec des variations
Oracle | Prise en charge, avec des variations
PostgreSQL | Prise en charge, avec des variations
Syntaxe SQL99 et description
    DROP TABLE table_name RESTRICT | CASCADE
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.
Syntaxe et variations dans Microsoft SQL Server
    DROP TABLE [database_name.][owner_name.]table_name [,...n]
    GO
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.
Syntaxe et variations dans MySQL
    DROP TABLE [IF EXISTS] table_name;
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.
Syntaxe et variations dans Oracle
    DROP TABLE [owner_name.]table_name [CASCADE CONSTRAINTS];
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.
Syntaxe et variations dans PostgreSQL
    DROP TABLE table_name;
PostgreSQL prend uniquement en charge la commande DROP TABLE de base.

DROP TRIGGER |
La commande DROP TRIGGER supprime un trigger associé à une table de la base de données active.
Editeur | Commande
--- | ---
SQL Server | Prise en charge, avec des variations
MySQL | Non prise en charge
Oracle | Prise en charge, avec des variations
PostgreSQL | Prise en charge, avec des variations
Syntaxe SQL99 et description
    DROP TRIGGER trigger_name
La commande DROP TRIGGER supprime un trigger de la base de données active. MySQL ne prend pas cette commande en charge.
Syntaxe et variations dans Microsoft SQL Server
    DROP TRIGGER [owner_name.]trigger_name [,...n]
    GO
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.
Syntaxe et variations dans Oracle
    DROP TRIGGER [owner_name.]trigger_name;
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.
Syntaxe et variations dans PostgreSQL
    DROP TRIGGER trigger_name ON table_name;
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.

DROP VIEW |
Cette supprime définitivement une vue de la base de données active.
Editeur | Commande
--- | ---
SQL Server | Prise en charge
MySQL | Non prise en charge
Oracle | Prise en charge
PostgreSQL | Prise en charge
Syntaxe SQL99 et description
    DROP VIEW view_name RESTRICT | CASCADE
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.
Syntaxe et variations dans Microsoft SQL Server
    DROP VIEW [owner_name.]view_name [,...n]
    GO
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.
Syntaxe et variations dans Oracle
    DROP VIEW [owner_name.]view_name;
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.
Syntaxe et variations dans PostgreSQL
    DROP VIEW view_name;
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.

FETCH |
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.
Editeur | Commande
--- | ---
SQL Server | Prise en charge
MySQL | Non prise en charge
Oracle | Prise en charge, avec des variations
PostgreSQL | Prise en charge, avec des variations
Syntaxe SQL99 et description
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.
Syntaxe et variations dans Oracle
    FETCH cursor_name
    {INTO variable_name1 [,...n] ]
    | BULK COLLECT INTO [collection_name [,...n] }
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.
Syntaxe et variations dans PostgreSQL
    FETCH [ FORWARD | BACKWARD | RELATIVE [ { [ # | ALL | NEXT | PRIOR ] } ]  ]
    [ count ]
    FROM cursor_name
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.
Exemples
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:
    FETCH FROM employee_new_hires_cursor
    INTO: emp_id,:fname,:lname,:job_id
La commande PostgreSQL qui suit récupère cinq enregistrements de la table employee:
    FETCH FORWARD 5 IN employee_new_hires_cursor;

GRANT |
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.
Editeur | Commande
--- | ---
SQL Server | Prise en charge, avec des variations
MySQL | Prise en charge, avec des variations
Oracle | Prise en charge, avec des variations
PostgreSQL | Prise en charge, avec des variations
Syntaxe SQL99 et description
    GRANT { ALL [PRIVILEGES] }
    | SELECT
    | INSERT [ (column_name [,...n]) ]
    | DELETE
    | UPDATE [ (column_name [,...n]) ]
    | REFERENCES [ (column_name [,...n]) ]
    | USAGE }[,...n]
    ON { [TABLE] table_name
    | DOMAIN domain_name
    | COLLATION collation_name
    | CHARACTER SET character_set_name
    | TRANSLATION translation_name }
    TO {grantee_name |  PUBLIC}
    [WITH GRANT OPTION]
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.
Syntaxe et variations dans Microsoft SQL Server
    GRANT { ALL [PRIVILEGES] }
    | SELECT
    | INSERT
    | DELETE
    | UPDATE
    | REFERENCES
    | EXECUTE
    | CREATE {DATABASE | DEFAULT | FUNCTION | PROCEDURE | RULE | TABLE | VIEW}
    | BACKUP {DATABASE | LOG} } [,...n]
    ON { {table_name | view_name} [(column [,...n])]
    | stored_procedure_name
    | extended_stored_procedure_name
    | user_defined_function_name
    | [(column [,...n] ON {table_name | view_name} }
    TO {grantee_name | PUBLIC} [,...n]
    [WITH GRANT OPTION]
    [AS {group | role}]
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.
Exemple
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:
    GRANT CREATE DATABASE, CREATE TABLE TO emily, sarah
    GO

    GRANT SELECT, INSERT, UPDATE, DELETE ON titles
    TO editors
    WITH GRANT OPTION
    GO
Syntaxe et variations dans MySQL
    GRANT { ALL PRIVILEGES
    | SELECT
    | INSERT [ (column_name [,...n]) ]
    | DELETE
    | UPDATE [ (column_name [,...n]) ]
    | REFERENCES [ (column_name [,...n]) ]
    | USAGE
    | ALTER
    | CREATE
    | DROP
    | FILE
    | INDEX
    | PROCESS
    | RELOAD
    | SHUTDOWN }[,...n]
    ON {table_name | * | *.* | database_name.*}
    TO grantee_name [IDENTIFIED BY 'password'] [,...n]
    [WITH GRANT OPTION]
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.
Exemple
L´exemple suivant accorde des permissions à deux utilisateurs dotés de mots de passe:
    GRANT SELECT ON employee TO Dylan IDENTIFIED BY 'porsche',
      kelly IDENTIFIED BY 'mercedes',
      emily IDENTIFIED BY 'saab';
Syntaxe et variations dans Oracle
    GRANT { ALL [PRIVILEGES] }
    {| GRANT ANY PRIVILEGE }
    {| SELECT | INSERT  | DELETE | UPDATE | REFERENCES }
    {| CREATE [ANY] {CLUSTER | CONTEXT | DATABASE| DATABASE LINK | DIMENSION
       | DIRECTORY | INDEXTYPE | INDEX | LIBRARY | OPERATOR | OUTLINE
       | PROCEDURE | PROFILE | ROLE | ROLLBACK SEGMENT | SEQUENCE | SESSION
       | SNAPSHOT | SYNONYM | TABLE | TABLESPACE | TRIGGER | TYPE |
       | USER | [MATERIALIZED] VIEW}
    | DROP [ANY] {...as CREATE...}
    | ALTER [ANYh] {...as CREATE...}
    | AUDIT SYSTEM
    | EXECUTE [ANY] {INDEXTYPE | OPERATOR | PROCEDURE | TYPE
    | BACKUP [ANY] {TABLE | DATABASE | LOG} } [,...n] }
    ON { [schema_name.]
    {table_name | view_name} [ (column [,...n]) ]
    | stored_procedure_name
    | extended_stored_procedure_name
    | user_defined_function_name
    | DIRECTORY directory_name
    | JAVA {SOURCE | RESOURCE} [schema_name.]object_name }
    TO {{grantee_name | role_name} [,...n] | PUBLIC}
    [WITH ADMIN OPTION];
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.
Catégorie de privilège | Privilège système | Description
--- | --- | ---
CLUSTER | CREATE CLUSTER | Accorde le privilège permettant de créer un cluster dans le schéma du bénéficiaire.
| CREATE ANY CLUSTER | Accorde le privilège permettant de créer un cluster dans n´importe quel schéma.
| ALTER ANY CLUSTER | Accorde le privilège permettant de modifier des clusters dans n´importe quel schéma.
| DROP ANY CLUSTER | Accorde le privilège permettant d´éliminer des clusters dans n´importe quel schéma.
CONTEXT | CREATE ANY CONTEXT | Accorde le privilège permettant de créer un espace de nom de contexte.
| DROP ANY CONTEXT | Accorde le privilège permettant d´éliminer n´importe quel espace de nom de contexte.
DATABASE | ALTER DATABASE | Accorde le privilège permettant de modifier la base de données.
| ALTER SYSTEM | Envoie des instructions ALTER SYSTEM.
| AUDIT SYSTEM | Envoie les instructions AUDIT sql_statements.
DATABASE LINKS | CREATE DATABASE LINK | Accorde le privilège permettant de créer des liaisons de base de données privées dans le schéma du bénéficiaire.
| CREATE PUBLICDATABASE LINK | Accorde le privilège permettant de créerdes liaisons de base de données publiques.
| DROP PUBLICDATABASE LINK | Accorde le privilège permettant d´éliminerdes liaisons de base de données publiques.
DIMENSIONS | CREATE DIMENSION | Accorde le privilège permettant de créer des dimensions dans le schéma du bénéficiaire.
| CREATE ANYDIMENSION | Accorde le privilège permettant de créer des dimensions dans n´importe quel schéma.
| ALTER ANYDIMENSION | Accorde le privilège permettant de modifier des dimensions dans n´importe quel schéma.
| DROP ANYDIMENSION | Accorde le privilège permettant d´éliminer des dimensions dans n´importe quel schéma.
DIRECTORIES | CREATE ANYDIRECTORY | Accorde le privilège permettant de créer des objets de base de données de répertoire.
| DROP ANYDIRECTORY | Accorde le privilège permettant d´éliminerdes objets de base de données de répertoire. .
INDEXTYPES | CREATE INDEXTYPE | Accorde le privilège permettant de créer un type d´index dans le schéma du bénéficiaire.
| CREATE ANYINDEXTYPE | Accorde le privilège permettant de créer un type d´index dans n´importe quel schéma.
| ALTER ANYINDEXTYPE | Modifie les types d´index dans n´importe quel schéma.
| DROP ANYINDEXTYPE | Accorde le privilège permettant de supprimer un type d´index dans n´importe quel schéma.
| EXECUTE ANYINDEXTYPE | Fait référence à un type d´index dans n´importe quel schéma.
INDEXES | CREATE ANY INDEX | Accorde le privilège permettant de supprimer un index de domaine ou un index de table dans n´importe quel schéma.
| ALTER ANY INDEX | Accorde le privilège permettant de modifier des index dans n´importe quel schéma.
| DROP ANY INDEX | Accorde le privilège permettant d´éliminer des index dans n´importe quel schéma.
| QUERY REWRITE | Permet d´effectuer une réécriture sur la base d´une vue matérialisée, ou crée un index fonctionnel, lorsque cette vue matérialisée ou cet index fait référence à des tables et des vues dans le schéma du bénéficiaire.
| GLOBAL QUERY REWRITE | Permet d´effectuer une réécriture sur la base d´une vue matérialisée, ou crée un index fonctionnel, lorsque cette vue matérialisée ou cet index fait référence à des tables et des vues dans un schéma quelconque.
LIBRARIES | CREATE LIBRARY | Accorde le privilège permettant de créer des bibliothèques de procédures/fonctions externes dans le schéma du bénéficiaire.
| CREATE ANY LIBRARY | Accorde le privilège permettant de créer des bibliothèques de procédures/fonctions externes dans n´importe quel schéma.
| DROP LIBRARY | Accorde le privilège permettant d´éliminer des bibliothèques de procédures/fonctions externes dans le schéma du bénéficiaire.
| DROP ANY LIBRARY | Accorde le privilège permettant d´éliminer des bibliothèques de procédures/fonctions externes dans n´importe quel schéma.
MATERIALIZED VIEWS (identique à SNAPSHOTS) | CREATE MATERIALIZED VIEW | Accorde le privilège permettant de créer une vue matérialisée dans le schéma du bénéficiaire.
| CREATE ANY MATERIALIZED VIEW | Accorde le privilège permettant de créer des vues matérialisées dans n´importe quel schéma.
| ALTER ANY MATERIALIZED VIEW | Accorde le privilège permettant de modifier des vues matérialisées dans n´importe quel schéma.
| DROP ANY MATERIALIZED VIEW | Accorde le privilège permettant d´éliminer des vues matérialisées dans n´importe quel schéma.
| GLOBAL QUERY REWRITE | Permet d´effectuer une réécriture sur la base d´une vue matérialisée, ou crée un index fonctionnel, lorsque cette vue matérialisée ou cet index fait référence à des tables ou des vues dans un schéma quelconque.
| QUERY REWRITE | Permet d´effectuer une réécriture sur la base d´une vue matérialisée, ou crée un index fonctionnel, lorsque cette vue matérialisée ou cet index fait référence à des tables ou des vues dans le schéma du bénéficiaire.
OPERATORS | CREATE OPERATOR | Accorde le privilège permettant de créer un opérateur et ses liaisons dans le schéma du bénéficiaire.
| CREATE ANYOPERATOR | Accorde le privilège permettant de créer un opérateur et ses liaisons dans n´importe quel schéma.
| DROP ANY OPERATOR | Accorde le privilège permettant d´éliminer un opérateur dans n´importe quel schéma.
| EXECUTE ANYOPERATOR | Fait référence à un opérateur dans n´importe quel schéma.
OUTLINES | CREATE ANY OUTLINE | Accorde le privilège permettant de créer des contours compatibles avec tout schéma utilisant les contours.
| ALTER ANY OUTLINE | Modifie les contours.
| DROP ANY OUTLINE | Accorde le privilège permettant d´éliminer les contours.
PROCEDURES | CREATE PROCEDURE | Accorde le privilège permettant de créer des procédures stockées, des fonctions et des chaînes dans le schéma du bénéficiaire.
| CREATE ANYPROCEDURE | Accorde le privilège permettant de créer des procédures stockées, des fonctions et des chaînes dans n´importe quel schéma.
| ALTER ANYPROCEDURE | Accorde le privilège permettant de modifier des procédures stockées, des fonctions et des chaînes dans n´importe quel schéma.
| DROP ANYPROCEDURE | Accorde le privilège permettant d´éliminer des procédures stockées, des fonctions et des chaînes dans n´importe quel schéma.
| EXECUTE ANYPROCEDURE | Exécute les procédures ou les fonctions (autonomes ou en chaînes).
PROFILES | CREATE PROFILE | Accorde le privilège permettant de créer des profils.
| ALTER PROFILE | Accorde le privilège permettant de modifier des profils.
| DROP PROFILE | Accorde le privilège permettant d´éliminer des profils.
ROLES | CREATE ROLE | Accorde le privilège permettant de créer des rôles.
| ALTER ANY ROLE | Accorde le privilège permettant de modifier n´importe quel rôle dans la base de données.
| DROP ANY ROLE | Accorde le privilège permettant d´éliminer des rôles.
| GRANT ANY ROLE | Accorde n´importe quel rôle dans la base de données.
ROLLBACK SEGMENTS | CREATE ROLLBACK SEGMENT | Accorde le privilège permettant de créer des rollback segments.
| ALTER ROLLBACK SEGMENT | Accorde le privilège permettant de modifier des rollback segments.
| DROP ROLLBACK SEGMENT | Accorde le privilège permettant d´éliminer des rollback segments.
SEQUENCES | CREATE SEQUENCE | Accorde le privilège permettant de créer des séquences dans le schéma du bénéficiaire.
| CREATE ANY SEQUENCE | Accorde le privilège permettant de créer des séquences dans n´importe quel schéma.
| ALTER ANY SEQUENCE | Accorde le privilège permettant de modifier n´importe quelle séquence dans la base de données.
| DROP ANY SEQUENCE | Accorde le privilège permettant d´éliminer des séquences dans n´importe quel schéma.
| SELECT ANY SEQUENCE | Fait référence à des séquences dans n´importe quel schéma.
SESSIONS | CREATE SESSION | Etablit une connexion à la base de données.
| ALTER RESOURCE COST | Etablit les coûts pour les ressources de session.
| ALTER SESSION | Envoie des instructions ALTER SESSION.
| RESTRICTED SESSION | Ouvre une session une fois que l´occurrence a été lancée au moyen de l´instruction STARTUP RESTRICT de SQL*Plus.
SNAPSHOTS (identique à MATERIALIZED VIEWS) | CREATE SNAPSHOT | Accorde le privilège permettant de créer des instantanés dans le schéma du bénéficiaire.
| CREATE ANYSNAPSHOT | Accorde le privilège permettant de créer des instantanés dans n´importe quel schéma.
| ALTER ANY SNAPSHOT | Accorde le privilège permettant de modifier n´importe quel instantané dans la base de données.
| DROP ANY SNAPSHOT | Accorde le privilège permettant d´éliminer des instantanés dans n´importe quel schéma.
| GLOBAL QUERY REWRITE | Permet d´effectuer une réécriture sur la base d´un instantané, ou crée un index fonctionnel, lorsque cet instantané ou cet index fait référence à des tables et des vues dans n´importe quel schéma.
| QUERY REWRITE | Permet d´effectuer une réécriture sur la base d´un instantané, ou crée un index fonctionnel, lorsque cet instantané ou cet index fait référence à des tables et des vues dans le schéma du bénéficiaire.
SYNONYMS | CREATE SYNONYM | Accorde le privilège permettant de créer des synonymes dans le schéma du bénéficiaire.
| CREATE ANY SYNONYM | Accorde le privilège permettant de créer des synonymes dans n´importe quel schéma.
| CREATE PUBLIC SYNONYM | Accorde le privilège permettant de créer des synonymes publics.
| DROP ANY SYNONYM | Accorde le privilège permettant d´éliminer des synonymes privés dans n´importe quel schéma.
| DROP PUBLIC SYNONYM | Accorde le privilège permettant d´éliminer des synonymes publics.
TABLES | CREATE ANY TABLE | Accorde le privilège permettant de créer des tables dans n´importe quel schéma. Le propriétaire du schéma qui contient la table doit avoir défini un quota d´espace pour la table dans l´espace de travail.
| ALTER ANY TABLE | Accorde le privilège permettant de modifier n´importe quelle table ou vue dans le schéma.
| BACKUP ANY TABLE | Emploie l´utilitaire Export pour exécuter une exportation incrémentielle des objets à partir du schéma d´autres utilisateurs.
| DELETE ANY TABLE | Supprime des lignes dans les tables, les partitions de tables ou les vues de n´importe quel schéma.
| DROP ANY TABLE | Accorde le privilège permettant d´éliminer ou de tronquer des tables ou des partitions de table dans n´importe quel schéma.
| INSERT ANY TABLE | Insère des lignes dans les tables ou les vues de n´importe quel schéma.
| LOCK ANY TABLE | Verrouille les tables ou les vues de n´importe quel schéma.
| UPDATE ANY TABLE | Met à jour les lignes dans les tables ou les vues de n´importe quel schéma.
| SELECT ANY TABLE | Interroge les tables, les vues ou les instantanés de n´importe quel schéma.
TABLESPACES | CREATE TABLESPACE | Accorde le privilège permettant de créer des espaces de table.
| ALTER TABLESPACE | Accorde le privilège permettant de modifier des espaces de table.
| DROP TABLESPACE | Accorde le privilège permettant d´éliminer des espaces de table.
| MANAGE TABLESPACE | Met les espaces de table hors ligne et en ligne, puis lance et arrête leurs sauvegardes.
| UNLIMITED TABLESPACE | Utilise une quantité illimitée d´un espace de table. Ce privilège outrepasse tous les quotas spécifiquement définis. Si vous révoquez ce privilège pour un utilisateur, les objets de son schéma propre sont conservés, mais toute nouvelle allocation de l´espace de table est refusée, sauf si les quotas de table d´espace spécifique l´autorisent. Vous ne pouvez pas accorder ce privilège système aux rôles.
TRIGGERS | CREATE TRIGGER | Accorde le privilège permettant de créer un trigger de base de données dans le schéma du bénéficiaire.
| CREATE ANY TRIGGER | Accorde le privilège permettant de créer des triggers de base de données dans n´importe quel schéma.
| ALTER ANY TRIGGER | Active, désactive ou compile les triggers de base de données dans n´importe quel schéma.
| DROP ANY TRIGGER | Accorde le privilège permettant de supprimer des triggers de base de données dans n´importe quel schéma.
| ADMINISTER DATABASE TRIGGER | Accorde le privilège permettant de créer un trigger sur DATABASE. (Vous devez également disposer du privilège CREATE TRIGGER ou CREATE ANY TRIGGER.)
TYPES | CREATE TYPE | Accorde le privilège permettant de créer des types d´objet et des corps de types d´objets dans le schéma du bénéficiaire.
| CREATE ANY TYPE | Accorde le privilège permettant de créer des types d´objet et des corps de types d´objet dans n´importe quel schéma.
| ALTER ANY TYPE | Accorde le privilège permettant de modifier des types d´objet dans n´importe quel schéma.
| DROP ANY TYPE | Accorde le privilège permettant d´éliminer des types d´objet et des corps de types d´objet dans n´importe quel schéma.
| EXECUTE ANY TYPE | Utilise et référence les types d´objet et de collection dans n´importe quel schéma, et appelle les méthodes d´un type d´objet dans n´importe quel schéma si vous accordez le privilège à un utilisateur spécifique. Si vous accordez le privilège EXECUTE ANY TYPE à un rôle, les utilisateurs disposant du rôle activé ne pourront pas appeler les méthodes d´un type d´objet dans n´importe quel schéma.
USERS | CREATE USER | Accorde le privilège permettant de créer des utilisateurs. Ce privilège permet également au créateur d´effectuer les opérations suivantes: Assigner des quotas à n´importe quel espace de table Définir des espaces de table par défaut et temporaires Assigner un profil dans le cadre d´une instruction CREATE USER
| ALTER USER | Accorde le privilège permettant de modifier n´importe quel utilisateur. Ce privilège autorise le bénéficiaire à effectuer les opérations suivantes: Modifier le mot de passe ou la méthode d´authentification d´un autre utilisateur Assigner des quotas à n´importe quel espace de table Définir des espaces de table par défaut et temporaires Assigner un profil et des rôles par défaut
| BECOME USER | Devient un autre utilisateur (cette opération est nécessaire si l´utilisateur effectue une importation de base de données complète).
| DROP USER | Accorde le privilège permettant d´éliminer des utilisateurs.
VIEWS | CREATE VIEW | Accorde le privilège permettant de créer des vues dans le schéma du bénéficiaire.
| CREATE ANY VIEW | Accorde le privilège permettant de créer des vues dans n´importe quel schéma.
| DROP ANY VIEW | Accorde le privilège permettant d´éliminer des vues dans n´importe quel schéma.
MISCELLANEOUS | ANALYZE ANY | Analyse tout index, table ou cluster d´un schéma.
| AUDIT ANY | Audite tout objet d´un schéma au moyen des instructions AUDIT schema_objects.
| COMMENT ANY TABLE | Effectue des commentaires sur toute table, vue ou colonne d´un schéma.
| FORCE ANYTRANSACTION | Force la validation ou l´annulation d´une transaction distribuée suspecte dans la base de données locale; entraîne l´échec d´une transaction distribuée.
| FORCE TRANSACTION | Force la validation ou l´annulation des transactions distribuées suspectes du bénéficiaire dans la base de données locale.
| GRANT ANYPRIVILEGE | Accorde n´importe quel privilège système.
| SYSDBA | Autorise l´utilisateur à effectuer les opérations suivantes: Exécuter les opérations STARTUP et SHUTDOWN ALTER DATABASE: ouvrir, monter, sauvegarder ou modifier les jeux de caractères CREATE DATABASE ARCHIVELOG et RECOVERY Inclut le privilège RESTRICTED SESSION
| SYSOPER | Autorise l´utilisateur à effectuer les opérations suivantes: Exécuter les opérations STARTUP et SHUTDOWN ALTER DATABASE OPEN/MOUNT/BACKUP &8212; ARCHIVELOG et RECOVERY Inclut le privilège RESTRICTED SESSION
Syntaxe et variations dans PostgreSQL
    GRANT { ALL
    | SELECT
    | INSERT
    | DELETE
    | UPDATE
    | RULE } [,...n]
    ON { object_name }
    TO {grantee_name | PUBLIC | GROUP group_name}
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.
Exemple
La prise en charge par PostgreSQL de l´instruction GRANT est fort simple:
    GRANT INSERT ON publishers TO PUBLIC;

    GRANT SELECT, UPDATE ON sales TO emily;

INSERT |
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:
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.) 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. 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.
Editeur | Commande
--- | ---
SQL Server | Prise en charge, avec des variations
MySQL | Prise en charge, avec des variations
Oracle | Prise en charge, avec des variations
PostgreSQL | Prise en charge
Syntaxe SQL99 et description
    INSERT [INTO] [[database_name.]owner.] {table_name | view_name} [(column_
        list)]
    {[DEFAULT] VALUES | VALUES (value[,...]) | SELECT_statement }
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.
Syntaxe Microsoft SQL Server et description
    INSERT [INTO] [[database_name.]owner.]
        {table_name | view_name} [(column_list)]
    {[DEFAULT] VALUES | list_of_values | SELECT_statement |
     EXEC[UTE] { procedure_name }
        [[@parameter_name=] {value [OUTPUT] | DEFAULT}[,...]}
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:
    INSERT INTO #ins_exec_container
    EXEC master..xp_cmdshell "dir c:\temp"
    GO
Syntaxe et variations dans MySQL
    INSERT [LOW_PRIORITY | DELAYED] [IGNORE]
    [INTO] [[database_name.]owner.] {table_name | view_name} [(column_list)]
    {VALUES (value[,...]) | SELECT_statement | SET column=value[,...n]}
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.
Syntaxe Oracle et description
    INSERT [INTO] [[database_name.]owner.] {table_name | view_name}
       [PARTITION partition_name | SUBPARTITION subpartition_name]
    [(column_list)]
    {VALUES (value1[,...n]) RETURNING expression1 [,...n] INTO variable1
       [,...n]
     |
    SELECT_statement
    [WITH {READ ONLY | CHECK OPTION [CONSTRAINT constraint_name]} }
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:
    INSERT authors (au_id, au_lname, au_fname, contract )
    VALUES ('111-11-1111', 'Rabbit', 'Jessica', 1)
    RETURNING hire_date INTO:temp_hr_dt;
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.
Syntaxe PostgreSQL et description
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.
Exemples
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:
    INSERT INTO authors (au_id, au_lname, au_fname, phone, address, city,
         state, zip, contract )
    VALUES ('111-11-1111', 'Rabbit', 'Jessica', DEFAULT, '1717 Main St', NULL,
        'CA', '90675', 1)
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:
    INSERT authors (au_id, au_lname, au_fname,  phone, contract )
    VALUES ('111-11-1111', 'Rabbit', 'Jessica', DEFAULT, 1)
Pour charger des données de la table sales dans la table new_sales, il est possible d´utiliser INSERT . . . SELECT:
    INSERT sales
        (stor_id,
        ord_num,
        ord_date,
        qty,
        payterms,
        title_id)
    SELECT
        CAST(store_nbr AS CHAR(4)),
        CAST(order_nbr AS VARCHAR(20)),
        order_date,
        quantity,
        SUBSTRING(payment_terms,1,12),
        CAST(title_nbr AS CHAR(1))
    FROM new_sales
    WHERE order_date >= '01/01/2000'         -- retrieve only the newer records

Opérateur LIKE |
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.
Editeur | Commande
--- | ---
SQL Server | Prise en charge, avec des variations
MySQL | Prise en charge, avec des variations
Oracle | Prise en charge, avec des variations
PostgreSQL | Prise en charge, avec des variations
Syntaxe SQL99 et description
    WHERE expression [NOT] LIKE string_pattern
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:
    SELECT *
    FROM authors
    WHERE lname LIKE 'LARS%'
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.
Opérateur générique | Exemple | Description
--- | --- | ---
% | Récupère tout enregistrement de ville dont le nom inclut la chaîne "ville". (Pris en charge par tous les éditeurs.)
    SELECT * FROM authors
    WHERE city LIKE '%ville%'
| Représente n´importe quelle chaîne; est similaire à l´opérateur * dans les opérations DOS.
[ ] | Récupère tout auteur dont le nom de famille est similaire à Carson, Carsen, Karson ou Karsen. (Non pris en charge par Oracle. Pris en charge par Microsoft SQL Server.)
    SELECT * FROM authors
    WHERE au_lname LIKE '[CK]ars[eo]n'
| Représente n´importe quelle valeur du jeu spécifié (par exemple, [abc]) ou n´importe quelle page (par exemple, [k-n]).
[^ ] | Récupère tout auteur dont le nom de famille se termine par arson ou arsen, sauf Larsen ou Larson. (Pris en charge par Microsoft SQL Server.)
    SELECT * FROM authors
    WHERE au_lname LIKE '[A-Z^L]ars[eo]n'
| Représente n´importe quelle caractère qui n´appartient pas au jeu ou à la plage spécifié.
_ (souligné) | Récupère tout auteur dont le prénom est différent de Sheryl ou Cheryl. (Pris en charge par tous les éditeurs.)
    SELECT * FROM authors
    WHERE au_fname NOT LIKE '_heryl'
| Représente n´importe quel caractère.
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 .

OPEN |
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.
Editeur | Commande
--- | ---
SQL Server | Prise en charge
MySQL | Non prise en charge
Oracle | Prise en charge
PostgreSQL | Prise en charge
Syntaxe SQL99 et description
    OPEN { cursor_name }
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]).
Exemple
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:
    DECLARE employee_cursor CURSOR FOR
      SELECT lname, fname
      FROM pubs.dbo.authors
      WHERE lname LIKE 'K%'

    OPEN employee_cursor

    FETCH NEXT FROM employee_cursor

    WHILE @@FETCH_STATUS = 0
    BEGIN
      FETCH NEXT FROM Employee_Cursor
    END

    CLOSE employee_cursor

    DEALLOCATE employee_cursor
    -- DEALLOCATE is specific to Microsoft SQL Server and non-ANSI
    -- standard.

Opérateurs |
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).
Editeur | Commande
--- | ---
SQL Server | Prise en charge, avec des variations
MySQL | Prise en charge, avec des variations
Oracle | Prise en charge, avec des variations
PostgreSQL | Prise en charge, avec des variations
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
Opérateurs arithmétiques
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.
Opérateurs arithmétiques | Signification
--- | ---
+ | Addition
- | Soustraction
* | Multiplication
/ | Division
% | Modulo (SQL Server uniquement); renvoie le reste d´une division sous la forme d´un nombre entier.
Dans Oracle et SQL Server, les opérateurs + et – permettent également d´exécuter des opérations arithmétiques sur les valeurs de date.
Opérateurs d'affectation
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.
Opérateurs binaires
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.
Opérateurs binaires | Signification
--- | ---
& | AND binaire (deux opérandes)
| | OR binaire (deux opérandes)
^ | OR exclusif binaire (deux opérandes)
Opérateurs de comparaison
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.
Opérateurs de comparaison | Signification
--- | ---
= | Egal à
> | Supérieur à
< | Inférieur à
>= | Supérieur ou égal à
<= | Inférieur ou égal à
<> | Différent de
!= | Différent de (ce n´est pas une norme ANSI)
!< | Supérieur à (ce n´est pas une norme ANSI)
!> | Inférieur à (ce n´est pas une norme ANSI)
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 à:
    SELECT *
       FROM Products
       WHERE ProductID >= @MyProduct
Opérateurs logiques
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.
Opérateurs logiques | Signification
--- | ---
ALL | TRUE si toutes les comparaisons d´un jeu ont la valeur TRUE
AND | TRUE si les deux expressions booléennes ont la valeur TRUE
ANY | TRUE si l´une des comparaisons d´un jeu a la valeur TRUE
BETWEEN | TRUE si l´opérande est inclus dans une plage
EXISTS | TRUE si une sous-requête contient des lignes
IN | TRUE si l´opérande est égal à une liste d´expressions
LIKE | TRUE si l´opérande correspond à un modèle
NOT | Inverse la valeur de tout autre opérateur booléen
OR | TRUE si l´une des expression booléenne a la valeur TRUE
SOME | TRUE si certaines comparaisons d´un jeu ont la valeur TRUE
Opérateurs unaires
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).
Opérateurs unaires | Signification
--- | ---
+ | La valeur numérique est positive
- | La valeur numérique est négative
~ | L´opérateur NOT binaire renvoie le complément du nombre (ne s´applique pas dans Oracle)
Priorité des opérateurs
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:
( ) (expressions entre parenthèses) +, -, ~ (opérateurs unaires) *, /, % (opérateurs mathématiques) +, - (opérateurs arithmétiques) =, >, <, >=, <=, <>, !=, !>, !< (opérateurs de comparaison) ^ (OR exclusif binaire), & (AND binaire), | (OR binaire) NOT AND ALL, ANY, BETWEEN, IN, LIKE, OR, SOME = (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:
    SELECT 2 * 4 + 5 FROM dual
    -- Evaluates to 8 + 5 which yields an expression result of 13.

    SELECT 2 * (4 + 5) FROM dual
    -- Evaluates to 2 * 9 which yields an expression result of 18.
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:
    SELECT 2 * (4 + (5 - 3) ) FROM dual
    -- Evaluates to 2 * (4 + 2) which further evaluates to 2 * 6, and
    -- yields an expression result of 12.

RETURN |
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.
Editeur | Commande
--- | ---
SQL Server | Prise en charge
MySQL | Prise en charge
Oracle | Prise en charge
PostgreSQL | Prise en charge
Syntaxe SQL99 et description
    RETURNS return_parameter_value | NULL
La fonction RETURN s´utilise dans une fonction pour mettre fin à son traitement. L´utilisation de la clause NULL met fin à la fonction sans renvoyer de valeur. Sinon, la valeur de paramètre spécifiée est renvoyée sous forme de variable ou d´expression littérale.
L´instruction RETURN est considérée comme une commande séparée dans SQL, mais elle est profondément entrelacée avec l´instruction CREATE FUNCTION . Reportez-vous à l´instruction CREATE FUNCTION pour plus de détails sur l´implémentation de RETURN par chaque éditeur.
Exemples
Cet exemple crée une fonction, qui renvoie à la session d´appel la valeur stockée dans la variable proj_rev:
    CREATE FUNCTION project_revenue (project IN varchar2)
    RETURN NUMBER
    AS
       proj_rev NUMBER(10,2);
    BEGIN
       SELECT SUM(DECODE(action,'COMPLETED',amount,0) -
              SUM(DECODE(action,'STARTED',amount,0)   +
              SUM(DECODE(action,'PAYMENT',amount,0)
       INTO proj_rev
       FROM construction_actions
       WHERE project_name = project;
       RETURN (proj_rev);
    END;
Cet exemple crée une fonction qui renvoie une valeur calculée à la session d´appel:
    CREATE FUNCTION metric_volume -- Input dimensions in centimeters.
       (@length decimal(4,1),
       @width decimal(4,1),
       @height decimal(4,1) )
    RETURNS decimal(12,3) -- Cubic Centimeters.
    AS
    BEGIN
       RETURN ( @length * @width * @height )
    END
    GO

REVOKE |
L´instruction REVOKE supprime les permissions accordées à un utilisateur, un groupe ou un rôle pour un objet de base de données ou une commande système spécifique.
Editeur | Commande
--- | ---
SQL Server | Prise en charge, avec des variations
MySQL | Prise en charge, avec des variations
Oracle | Prise en charge, avec des variations
PostgreSQL | Prise en charge, avec des variations
Syntaxe SQL99 et description
    REVOKE [GRANT OPTION FOR]
    { ALL PRIVILEGES }
    | SELECT
    | INSERT
    | DELETE
    | UPDATE
    | REFERENCES
    | USAGE }[,...n]
    ON { [TABLE] table_name
    | DOMAIN domain_name
    | COLLATION collation_name
    | CHARACTER SET character_set_name
    | TRANSLATION translation_name }
    FROM {grantee_name | PUBLIC} [,...n]
    {CASCADE | RESTRICT}
REVOKE privilege_name ON object_name FROM grantee_name permet de révoquer pour un seul utilisateur un privilège spécifique applicable à un objet de base de données particulier. La clause PUBLIC permet de révoquer pour tous les utilisateurs un privilège spécifique applicable à un objet de base de données particulier. WITH GRANT OPTION permet de révoquer les permissions au moyen de la clause REVOKE GRANT OPTION FOR.
L´option RESTRICT révoque uniquement le privilège spécifié. L´option CASCADE révoque le privilège spécifié, ainsi que tous les privilèges qui en dépendent. Une révocation en cascade peut présenter un comportement différent en fonction de la plate-forme de base de données utilisée; veillez donc à lire la documentation de l´éditeur afin de connaître l´implémentation correcte pour cette option.
Syntaxe et variations dans Microsoft SQL Server
    REVOKE [GRANT OPTION FOR]
    {ALL [ PRIVILEGES ]
    | SELECT
    | INSERT
    | DELETE
    | UPDATE
    | REFERENCES
    | EXECUTE
    | CREATE {DATABASE | DEFAULT | FUNCTION | PROCEDURE | RULE | TABLE | VIEW}
    | BACKUP {DATABASE | LOG} } [,...n]
    ON { {table_name | view_name} [(column [,...n])]
    | stored_procedure_name
    | extended_stored_procedure_name
    | user_defined_function_name
    | [(column [,...n] ON {table_name | view_name} }
    {TO | FROM} {grantee_name} [,...n]
    [CASCADE]
    [AS {group_name | role_name} ]
Cette commande est surtout compatible avec SQL99, à l´exception des extensions apportées par la commande GRANT .
Si les commandes ont été accordées à un utilisateur pour lequel WITH GRANT OPTION est activé, il faut utiliser à la fois WITH GRANT OPTION et CASCADE pour révoquer le privilège en question.
REVOKE s´utilise uniquement dans la base de données active. REVOKE permet également de désactiver les paramètres DENY.
Microsoft SQL Server prend de plus en charge l´instruction DENY . DENY utilise une syntaxe similaire à celle de REVOKE. Cependant, sa conception est différente dans la mesure où REVOKE neutralise les privilèges d´un utilisateur, tandis que DENY les interdit explicitement. L´instruction DENY permet d´interdire à un utilisateur ou un rôle l´accès à un privilège.
Exemple
    REVOKE CREATE DATABASE, CREATE TABLE FROM emily, sarah
    GO

    REVOKE GRANT OPTION FOR
    SELECT, INSERT, UPDATE, DELETE ON titles
    TO editors
    GO
Syntaxe et variations dans MySQL
    REVOKE { ALL PRIVILEGES
    | SELECT
    | INSERT [ (column_name [,...n]) ]
    | UPDATE [ (column_name [,...n]) ]
    | REFERENCES [ (column_name [,...n]) ]
    | DELETE
    | USAGE
    | ALTER
    | CREATE
    | DROP
    | FILE
    | INDEX
    | PROCESS
    | RELOAD
    | SHUTDOWN } [,...n]
    ON {table_name | * | *.* | database_name.*}
    FROM user_name [,...n]
L´instruction REVOKE annule les permissions préalablement accordées à un ou plusieurs utilisateurs. Les permissions peuvent faire l´objet d´une révocation globale, comme décrit dans le cadre de l´instruction GRANT. De plus, l´implémentation de REVOKE dans MySQL n´annule pas explicitement les permissions relatives aux objets éliminés. Il est donc nécessaire de révoquer (REVOKE) explicitement les permissions applicables à une table, même si cette dernière est éliminée. Pour le reste, MySQL respecte la norme SQL99 applicable à la commande REVOKE.
Exemple
La première commande révoque tous les privilèges applicables à la table sales pour Emily et Dylan, tandis que la seconde révoque tous les privilèges pour l´utilisateur Kelly dans la base de données active:
    REVOKE ALL PRIVILEGES ON sales FROM emily, dylan;

    REVOKE * employee FROM kelly;
Syntaxe et variations dans Oracle
    REVOKE {ALL [PRIVILEGES] | [object_privilege] }
    ON { [schema_name.][object] | [DIRECTORY directory_object_name] }
    FROM {grantee_name | role | PUBLIC} [,...n]
    [CASCADE [CONSTRAINTS] ] [FORCE];

    REVOKE {system_privilege | role}
    FROM {grantee_name | role | PUBLIC} [,...n];
La commande REVOKE permet de révoquer non seulement les privilèges objet et système, mais elle peut également révoquer un rôle pour un utilisateur spécifique ou un autre rôle. Reportez-vous à l´instruction GRANT pour de plus amples informations sur les privilèges objet et système spécifiquement pris en charge par la commande REVOKE.
Les deux formes de la commande REVOKE, REVOKE object_privilege et REVOKE system_privilege, sont incompatibles. Vous ne devez pas essayer de les inclure dans une même instruction.
La révocation des privilèges d´un utilisateur révoque en même temps les privilèges qu´il a accordés à d´autres utilisateurs.
Les utilisateurs qui possèdent le privilège système GRANT ANY ROLE peuvent également révoquer n´importe quel rôle. La commande REVOKE peut uniquement révoquer les privilèges qui ont été spécifiquement accordés au moyen de la commande GRANT, mais non les privilèges accordés par le biais de rôles ou du système d´exploitation.
La clause ON DIRECTORY identifie un objet répertoire dont les permissions sont révoquées. La clause CASCADE CONSTRAINTS supprime toutes les contraintes d´intégrité référentielle créées par les utilisateurs lorsque leur privilège REFERENCES est révoqué. La clause FORCE révoque les permissions EXECUTE pour les objets table et type connexes définis par l´utilisateur. Ces objets seront donc marqués comme non valides et inutilisables jusqu´à recompilation.
Exemples
Pour révoquer un rôle pour un utilisateur:
    REVOKE read-only FROM sarah;
Pour révoquer un privilège de commande système:
    REVOKE CREATE ANY SEQUENCE, CREATE ANY DIRECTORY FROM read_only;
Pour révoquer un privilège REFERENCES:
    REVOKE REFERENCES
    ON pubs_new_york.emp
    FROM dylan
    CASCADE CONSTRAINTS;
Syntaxe et variations dans PostgreSQL
    REVOKE { ALL
    | SELECT
    | INSERT
    | DELETE
    | UPDATE
    | RULE
    | REFERENCES
    | USAGE} [,...n]
    ON {object_name}
    TO {grantee_name | PUBLIC | GROUP group_name}
    {CASCADE | RESTRICT}
L´accès aux tables, vues et séquences peut être révoqué dans PostgreSQL. Cette commande est autrement identique à la commande SQL99. Reportez-vous à la présentation de la syntaxe de REVOKE pour SQL99, ainsi qu´à la présentation de GRANT pour SQL99.

ROLLBACK |
L´instruction ROLLBACK annule une transaction ou rétablit l´état qu´elle avait à un SAVEPOINT préalablement déclaré. Elle ferme les curseurs ouverts et libère les verrous selon le même principe que COMMIT.
Editeur | Commande
--- | ---
SQL Server | Prise en charge, avec des variations
MySQL | Non prise en charge
Oracle | Prise en charge
PostgreSQL | Prise en charge
Syntaxe SQL99 et description
    ROLLBACK [WORK]
    [TO SAVEPOINT savepoint_name]
Outre qu´elle finalise une seule opération de manipulation de données ou un groupe de telles opérations, l´instruction ROLLBACK annule toutes les transactions jusqu´à la dernière instruction BEGIN ou SAVEPOINT émise.
SQL99 propose les nouveaux mots-clé optionnels AND CHAIN. Aucun des quatre éditeurs ne prend cette commande en charge pour le moment. Cette nouvelle syntaxe est la suivante:
    ROLLBACK [WORK] [AND [NO] CHAIN]
L´option AND CHAIN indique au SGBD de mettre fin à la transaction en cours, tout en partageant l´environnement de transaction commun (le niveau d´isolation de transaction, par exemple) avec la transaction suivante. L´option AND NO CHAIN met fin à la transaction unique. D'un point de vue fonctionnel, la commande ROLLBACK est équivalente à la commande ROLLBACK WORK AND NO CHAIN.
Syntaxe et variations dans Microsoft SQL Server
    ROLLBACK [TRAN[SACTION] [transaction_name |
     @tran_name_variable |
    savepoint_name | @savepoint_variable] ]
ROLLBACK annule toutes les modifications de données apportées à la transaction active ou à un point de reprise existant spécifique. Si elle est émise toute seule, l´instruction ROLLBACK annule la transaction ouverte active. ROLLBACK libère normalement les verrous, mais tel n´est pas le cas pour une annulation à un point de reprise. L´instruction ROLLBACK a un comportement similaire à COMMIT en ce qui concerne les triggers imbriqués, puisqu´elle décrémente la variable système @@TRANCOUNT d´une unité.
Emise dans un trigger, l´instruction ROLLBACK TRANSACTION annule toutes les modifications de données, y compris celles exécutées par le trigger, jusqu´à l´emplacement de l´instruction ROLLBACK. Les triggers imbriqués ne sont pas exécutés s´ils suivent une instruction ROLLBACK dans un trigger; cependant, le rollback n´a aucune incidence sur les instructions incluses dans le trigger qui le suit.
Syntaxe et variations dans Oracle
    ROLLBACK [WORK] [TO savepoint_name] [FORCE text];
ROLLBACK annule toutes les modifications de données apportées à la transaction ouverte active ou à un point de reprise spécifique. L´implémentation de cette commande dans Oracle respecte scrupuleusement la norme SQL, sauf en ce qui concerne l´option FORCE. ROLLBACK FORCE revient à une transaction distribuée suspecte. Ces transactions font l´objet d´une description dans la vue système Oracle, DBA_2PC_PENDING.
Syntaxe et variations dans PostgreSQL
    {ROLLBACK | ABORT} [WORK | TRANSACTION];
ROLLBACK annule toutes les modifications de données apportées à la transaction ouverte active ou à un point de reprise spécifique. PostgreSQL prend en charge l´option WORK de SQL99 et l´option TRANSACTION. PostgreSQL ne prend pas en charge le retour à un point de reprise. L´option ABORT peut servir de synonyme complet pour ROLLBACK.
Exemple
Le lot Transact-SQL suivant utilise COMMIT et ROLLBACK dans Microsoft SQL Server. Il insère un enregistrement dans la table sales. En cas d´échec, la transaction est annulée; si l´instruction aboutit, la transaction est validée:
    BEGIN TRAN -- initializes a transaction

    -- the transaction itself
    INSERT INTO sales
    VALUES('7896','JR3435','Oct 28 1997',25,'Net 60','BU7832')

    -- some error-handling in the event of a failure
    IF @@ERROR <> 0
    BEGIN
        -- raises an error in the event log and skips to the end
        RAISERROR 50000 'Insert of sales record failed'
        ROLLBACK WORK
        GOTO end_of_batch
    END

    -- the transaction is committed if no errors are detected
    COMMIT TRAN

    -- the GOTO label that enables the batch to skip to the end without
    -- committing
    end_of_batch:
    GO

SAVEPOINT |
Cette commande crée un point de reprise dans la transaction active. La commande SAVEPOINT permet de diviser les transactions en points d´interruption logiques. Vous pouvez spécifier plusieurs points de reprise dans une même transaction. La commande SAVEPOINT présente un avantage primordial: les transactions peuvent faire l´objet d´un retour à un marqueur de point de reprise unique, au moyen de la commande ROLLBACK.
Editeur | Commande
--- | ---
SQL Server | Prise en charge, avec des variations
MySQL | Non prise en charge
Oracle | Prise en charge
PostgreSQL | Non prise en charge
Syntaxe SQL99 et description
    SAVEPOINT savepoint_name
Il est désonseillé, bien que certains éditeurs l´autorisent, de dupliquer les noms de points de reprise au sein d´une même transaction. Il est également inclure des identificateurs de points de reprise de remplacement (au format:X) afin que le SGBD puisse assurer le suivi du point de reprise sur la base d´un nombre entier plutôt que d´un nom. Les éditeurs ne prennent pas tous en charge cette approche, qui est de toute façon déconseillée.
SQL99 prend en charge l´instruction RELEASE SAVEPOINT savepoint_name, et cela permet d´éliminer un point de reprise existant. Cependant, cette instruction n´est prise en charge par aucun des éditeurs mentionnés dans cet ouvrage.
Syntaxe et variations dans Microsoft SQL Server
    SAVE TRAN[SACTION] {savepoint_name | @savepoint_variable}
Microsoft SQL Server ne prend pas en charge la commande SAVEPOINT. Il utilise à la place la commande SAVE . Si vous ne voulez pas déclarer le nom littéral du point de reprise, vous pouvez faire référence à une variable contenant le nom de ce point de reprise.
A l´exécution de la commande ROLLBACK TRAN savepoint_name, SQL Server retourne la transaction au point de reprise approprié, puis poursuit le traitement au niveau de la prochaine commande Transact-SQL valide suivant l´instruction ROLLBACK . Enfin, la transaction doit se terminer par une instruction COMMIT ou ROLLBACK.
Syntaxe et variations dans Oracle
    SAVEPOINT savepoint_name
Oracle prend totalement en charge l´implémentation SQL99.
Exemple
Cet exemple exécute plusieurs modifications de données, retourne la transaction à un point de reprise, puis l´annule complètement:
    INSERT INTO sales VALUES('7896','JR3435','Oct 28 1997',25,'Net
    60','BU7832');

    SAVEPOINT after_insert;

    UPDATE sales SET terms = 'Net 90'
    WHERE sales_id = '7896';

    SAVEPOINT after_update;

    DELETE sales;

    ROLLBACK TO after_insert;
    ROLLBACK;

SELECT |
L´instruction SELECT récupère des lignes, des colonnes et des valeurs dérivées d´une ou plusieurs des tables d´une base de données.
Editeur | Commande
--- | ---
SQL Server | Prise en charge, avec des variations (prise en charge des jointures ANSI)
MySQL | Prise en charge, avec des variations (prise en charge partielle des jointures ANSI)
Oracle | Prise en charge, avec des variations (pas de prise en charge des jointures ANSI)
PostgreSQL | Prise en charge, avec des variations (prise en charge partielle des jointures ANSI)
Syntaxe SQL99 et description
La syntaxe complète de l´instruction SELECT allie puissance et complexité, mais vous pouvez la décomposer en plusieurs clauses principales:
    SELECT [ALL | DISTINCT] select_list
    FROM table_name1 [,..., table_nameN]
    [JOIN join_condition]
    [WHERE search_condition]
    [GROUP BY group_by_expression]
    [HAVING search_condition]
    [ORDER BY order_expression [ASC | DESC] ]
Chacune des clauses de l´instruction SELECT possède une action spécifique. Il est donc possible de parler individuellement de la clause FROM, de la clause WHERE ou de la clause GROUP BY. Cependant, les requêtes n´exigent pas systématiquement chacune de ces clauses. Une requête exige au minimum une liste d´éléments SELECT et une clause FROM. (Microsoft SQL Server et PostgreSQL prennent tous deux en charge certains types de requêtes qui n´exigent pas de clause FROM. Reportez-vous aux exemples ci-dessous pour plus d´informations.)
Liste d´éléments SELECT
La liste d´éléments SELECT inclut en gros tous les éléments d´information qu´un utilisateur veut récupérer du serveur. Elle peut contenir différents types d´éléments. Il est possible de récupérer des chaînes littérales, des fonctions agrégat et des calculs mathématiques. Dans Microsoft SQL Server, la liste d´éléments SELECT peut contenir une sous-requête.
ALL est la valeur par défaut; autrement dit, tous les enregistrements sont renvoyés, même les valeurs par défaut. Le mot-clé DISTINCT indique à la requête de filtrer tous les enregistrements dupliqués. Le jeu de résultats ne va donc inclure qu´une seule occurrence des enregistrements identiques.
Diverses autres règles s´appliquent aux éléments susceptibles de figurer dans la liste d´éléments SELECT:
Les colonnes voulues doivent normalement être séparées par une virgule. L´astérisque (*) a une fonction de raccourci pour récupérer toutes les colonnes des diverses tables indiquées dans la clause FROM, telles qu´elles apparaissent dans l´instruction CREATE TABLE. Des alias de colonne sont ajoutés afin de remplacer les en-têtes de colonne par défaut utilisés dans les résultats. Utilisez l´alias format column AS "alias" ou l´alias de colonne. Cette fonction est particulièrement utile lorsque le libellé ou la longueur d´un en-tête de colonne n´en facilite pas la compréhension. Par exemple: Lorsqu´elles sont prises en charge, les variables locales et globales peuvent apparaître sous la forme d´un élément de liste SELECT. Le double-tiret (&8212;) ou la combinaison barre oblique-astérisque ( /* ... */) permettent de disperser des commentaires dans l´ensemble d´une instruction SQL ou Transact-SQL. Le double-tiret indique à la requête d´ignorer le texte qui le suit, jusqu´à la fin de la ligne. La barre oblique indique à la requête d´ignorer le texte placé entre la combinaison barre oblique-astérique et la combinaison barre oblique inverse-astérisque. Le nom de la table doit être utilisé comme préfixe du nom de colonne lorsque la requête porte sur plusieurs tables. Sur le plan technique, le nom de la table doit s´appliquer à n´importe quelle colonne des deux tables (cette procédure est de toute façon recommandée). Par exemple, les tables jobs et employee contiennent la colonne job_id: Le nom du schéma ou du propriétaire doit porter le préfixe d´une colonne s´il provient d´un contexte différent de celui de l´utilisateur actuel. Si la table est la propriété d´un autre nom d´utilisateur, ce dernier doit être inclus dans la référence de colonne. Par exemple, supposons que cet exemple de requête est exécuté dans la base de données PUBS et qu´il récupère également des données de la base de données SALES: Les expressions littérales peuvent servir d´éléments de liste SELECT. Les calculs mathématiques peuvent être entrés sous la forme d´éléments de liste SELECT. Aucune instruction FROM n´est nécessaire dans Microsoft SQL Server. Dans Oracle, le calcul doit être exécuté par rapport à la table système DUAL. La table permet à la commande SELECT de récupérer des valeurs lorsqu´il n´existe aucune table. Par exemple:
Clause FROM
La clause FROM a généralement une double action: elle répertorie les tables et les vues à partir desquelles une requête a récupéré ses données (en séparant les noms de table par une virgule); et elle assigne un alias aux noms de table longs, afin de faciliter nettement le codage des longues requêtes. Il existe deux méthodes permettant d´attribuer un alias dans la clause FROM: entrer le nom de la table, un espace et l´alias; entrer le nom de la table, AS et l´alias. L´exemple ci-dessous illustre chacune des deux techniques. Par exemple, une requête permettant de récupérer des données à partir de plusieurs tables peut inclure une clause FROM et WHERE codée comme suit:
    SELECT   e.emp_id,
             e.fname,
             e.lname,
             j.job_desc
    FROM     employee e,
             jobs AS  j
    WHERE    e.job_id = j.job_id
    ORDER BY e.fname,
             e.lname
Une fois l´alias assigné dans une requête, vous devez veiller à l´utiliser exclusivement pour des références de tables dans cette requête. Vous ne devez pas mélanger dans une requête les références renvoyant au nom de table complet et l´alias.
Cette requête récupère le emp_id (prénom et nom de chacun des employés stockés dans la table employee) et joint le job_id de l´employé (numéro de code) à la description de poste complète figurant dans la table JOBS.
Clause JOIN
Dans les implémentations qui ne respectent pas les normes ANSI, l´opération de jointure est exécutée dans la clause WHERE (décrite dans la section relative aux clauses WHERE). Dans le cadre des normes ANSI SQL-92, les jointures sont exécutées dans la clause JOIN de la requête. Ces méthodes de jointure sont appelées respectivement style thêta et style ANSI de jointure.
Pour récupérer les données jointes à partir de deux tables ou plus, il faut d´abord que ces tables partagent une relation significative. Les tables à joindre doivent posséder une ou plusieurs colonnes partageant un ensemble commun de valeurs qui permette d´établir entre elles une liaison significative. On appelle clé de jointure ou clé commune cette colonne (ou ces colonnes). Dans la plupart des cas &8212; mais pas dans tous &8212;, la clé de jointure correspond à la clé primaire d´une table et à la clé étrangère d´une autre table. Les jointures sont possibles tant que les données des colonnes sont en correspondance.
Dans la base de données PUBS, les tables employee et jobs contiennent toutes les deux une colonne job_id. job_id représente donc la clé commune entre les tables employee et jobs.
Pour exécuter une requête sur la base d´une jointure de style ANSI, vous devez répertorier la première table et le mot-clé JOIN, suivis de la table à joindre. Une fois la seconde table entrée, tapez le mot-clé ON et la condition de jointure qui aurait servi dans l´ancienne requête. L´exemple suivant illustre la requête originale, maintenant en style ANSI:
    SELECT   e.emp_id,
             e.fname,
             e.lname,
             j.job_desc
    FROM     employee AS e
    JOIN     jobs AS j ON e.job_id = j.job_id
    ORDER BY e.fname,
             e.lname
Types de jointure
Vous pouvez résoudre ces problèmes en utilisant des jointures de style ANSI et la combinaison combinaison égal-astérisque (`=* ' ) pour Microsoft SQL Server ou plus-astérisque (`+* ') pour Oracle dans les jointures thêta. La liste qui suit vous indique la marche à suivre pour contrôler ce comportement dans les jointures:
Jointure croisée Spécifie le produit cartésien complet de deux tables. A chaque enregistrement de la première table sont joints tous les enregistrements de la seconde table, et le jeu de résultats est extrêmement volumineux. Cette commande, aussi appelée « produit cartésien », revient à ignorer la condition de jointure. L´utilisation des jointures croisées est vivement déconseillée (elles sont actuellement prises en charge par Microsoft SQL Server): Jointure interne Indique qu´il faut éliminer les lignes sans correspondance dans les deux tables de la jointure. Si aucun type de jointure n´est explicitement défini dans le style ANSI, le style par défaut est utilisé (cette fonction est actuellement prise en charge par Microsoft SQL Server, PostgreSQL et MySQL): Jointure [externe] gauche Spécifie que les enregistrements doivent tous être renvoyés à partir de la table placée dans la partie gauche de l´instruction join. Si un enregistrement provenant de la table gauche ne dispose d´aucun enregistrement correspondant dans la table droite de la jointure, il est quand même renvoyé. Les colonnes placées dans la table de droite renvoient des valeurs NULL. (Dans ce cas, tous les enregistrements de la table employees sont renvoyés, qu´ils possèdent ou non une description de poste.) Les spécialistes recommandent souvent, dans le mesure du possible, de configurer les jointures externes en tant que jointures gauches par souci de cohérence (cette fonction est actuellement prise en charge par Microsoft SQL Server): Jointure [externe] droite Spécifie que les enregistrements doivent tous être renvoyés à partir de la table placée dans la partie droite de l´instruction join, même si la table de gauche ne possède aucun enregistrement correspondant. Les colonnes placées dans la table de gauche renvoient des valeurs NULL. (Dans l´exemple, tou les enregistrements de la table jobs sont renvoyés avec ou sans enregistrement correspondant dans la table employee [cette fonction est actuellement prise en charge par Microsoft SQL Server]): Jointure complète Spécifie que les lignes des deux tables doivent toutes être renvoyées, quels que soient les enregistrements correspondants dans l´autre table. Le jeu de résultats indique des valeurs NULL s´il n´existe aucune donnée dans la jointure (cette fonction est actuellement prise en charge par Microsoft SQL Server):
Il est actuellement plus facile de comprendre les jointures dans le style ANSI que dans le style thêta, puisque la requête indique clairement la table qui se trouve dans la partie gauche d´une instruction LEFT JOIN et celle qui se trouve dans la partie droite d´une instruction RIGHT JOIN.
La syntaxe à utiliser pour exécuter une requête similaire sur la base de clés complexes et de tables jointes repose dans une large mesure sur une extension de la même technique.
Exemple de jointure multitable
    --Requête dans le style thêta avec tables multiples
    SELECT   a.au_lname,
             a.au_fname,
             t2.title
    FROM     authors a,
             titleauthor t1,
             titles t2
    WHERE    a.au_id     = t1.au_id
      AND    t1.title_id = t2.title_id
    ORDER BY t2.title

    -- Requête dans le style ANSI avec tables multiples
    SELECT   a.au_lname,
             a.au_fname,
             t2.title
    FROM     authors a
    JOIN     titleauthor AS t1 ON a.au_id     = t1.au_id
    JOIN     titles      AS t2 ON t1.title_id = t2.title_id
    ORDER BY t2.title
Exemple de jointure multiclé:
    --Requête dans le style thêta avec clés multiples
    SELECT   s1.store_id,
             s1.title_id,
             s2.qty
    FROM     sales s1,
             sales_projections s2
    WHERE    s1.store_id = s2.store_id
      AND  s1.title_id = s2.title_id
    ORDER BY s1.store_id, s2.title_id

    -- Requête dans le style ANSI avec clés multiples
    SELECT   s1.store_id,
             s1.title_id,
             s2.qty
    FROM     sales s1
    JOIN     sales_projections s2 ON s1.store_id = s2.store_id
       AND   s1.title_id = s2.title_id
    ORDER BY s1.store_id, s2.title_id
Clause WHERE
La clause WHERE est un composant extrêmement puissant de l´instruction SELECT. La clause WHERE fournit la plupart des conditions de recherche permettant d´éliminer de la requête les données indésirables; les conditions de recherche restantes sont satisfaites sur la base de la clause HAVING (présentée dans la suite de cette section).
Une clause WHERE mal conçue peut ruiner une bonne instruction SELECT; il convient donc de maîtriser dans ses moindres nuances la clause WHERE. L´exemple qui suit illustre une requête type et une clause WHERE en plusieurs parties:
    SELECT   a.au_lname,
             a.au_fname,
             t2.title,
             convert(char,t2.pubdate)
    FROM     authors a
    JOIN     titleauthor t1 ON a.au_id = t1.au_id
    JOIN     titles t2 ON t1.title_id = t2.title_id
    WHERE    (t2.type = 'business' OR t2.type = 'popular_comp')
      AND    t2.advance > $5500
    ORDER BY t2.title
Lorsque vous examinez la requête, vous pouvez remarquer que les parenthèses déterminent l´ordre de traitement des critères WHERE sur la base de la priorité des opérateurs.
L´ordre de tri par défaut de la base de données détermine la manière dont la clause WHERE récupère le jeu de résultats pour une requête. Par exemple, Microsoft SQL Server, qui allie (par défaut) l´ordre dictionnaire et l´insensibilité à la casse, ne fait aucune différence entre « Smith », « smith » et « SMITH ». En revanche, Oracle, qui allie l´ordre dictionnaire et la sensibilité à la casse, différencie les valeurs « Smith », « smith » et « SMITH ».
La clause WHERE propose davantage de fonctions spécifiques que cet exemple ne l´illustre. Le Tableau 3.9 propose un bref récapitulatif des fonctions communes de la clause WHERE.
Forme courte de condition de recherche | Syntaxe | Exemple | Usage et description
--- | --- | --- | ---
Vérification booléenne simple |
    WHERE [NOT] expression
    comparison_operator  expression
    SELECT au_id
    FROM   authors
    WHERE  au_id = '172-32-1176'

    SELECT au_id
    FROM   authors
    WHERE  au_lname NOT LIKE 'John%'
| Les opérateurs <, >, <>, >=, <= et = permettent de comparer des expressions. Il existe de plus divers opérateurs de comparaison spéciaux (LIKE, par exemple), dont vous trouverez la description dans la suite de ce tableau. Le mot-clé NOT inverse les vérifications booléennes sur la base des opérateurs normaux <, >, <>, >=, <= et =, en plus des opérateurs spéciaux tels que LIKE, NULL, BETWEEN, IN, EXISTS, ANY, et ALL.
Conditions de recherche multiples |
    WHERE [NOT] expression
    comparison_operator expression
    {AND | OR}
    expression comparison_operator
    expression
    SELECT au_id
    FROM   authors
    WHERE  au_id = '172-32-1176'
      AND  au_lname = 'White'
| AND fusionne plusieurs conditions et renvoie les résultats lorsque les deux conditions ont la valeur true. AND a priorité sur les autres opérateurs.Les parenthèses utilisées dans la clause WHERE ont une incidence supplémentaire sur la priorité des opérateurs. OR fusionne plusieurs conditions et renvoie les résultats lorsque l´une des conditions a la valeur true. OR occupe le second niveau de priorité après AND.
Vérification NULL |
    WHERE [NOT] column_name IS [NOT]
    NULL
    SELECT *
    FROM   titles
    WHERE  price IS NULL
| IS NULL et IS NOT NULL indique à la requête de rechercher les valeurs null (ou toutes les valeurs sauf les valeurs null).
Vérification JOIN |
    WHERE [NOT] column_value(s)
    [(+)]=[(+)] column_value(s)
Ou
    WHERE [NOT] column_value(s)
    [*]=[*] column_value(s)
    SELECT a.au_lname,
           a.au_fname,
           t2.title
    FROM  authors a,
          titleauthor t1,
          titles t2
    WHERE a.au_id = t1.au_id
      AND t1.title_id = t2.title_id
    ORDER BY t2.title
| Une vérification JOIN repose sur l´évaluation de la clé commune entre deux tables au moins. Pour exécuter des jointures externes dans PostgreSQL, il faut ajouter l´astérisque sur le côté à partir duquel les enregistrements seront récupérés. Dans Oracle, les jointures externes sont activées par l´ajout, sur le côté pour lequel les valeurs null sont autorisées, du signe plus entre parenthèses (+) [cette méthode est, dans ses grandes lignes, l´inverse de la méthode reposant sur l´emploi de l´astérisque]. Reportez-vous à la section précédente relative aux clauses JOIN pour de plus amples informations.
Vérification LIKE |
    WHERE [NOT] column_name [NOT]
    LIKE 'match_string'
    /* get any phone number starting with 415 */
    SELECT * FROM authors
    WHERE phone LIKE '415%'
| LIKE indique à la requête d´utiliser le modèle correspondant sur la chaîne entre guillemets. Les symboles génériques sont détaillés sous l´entrée LIKE.
Vérification EXIST |
    WHERE [NOT] EXISTS (subquery)
    SELECT p1.pub_name
    FROM publishers p1
    WHERE EXISTS
        (SELECT *
        FROM titles t1
        WHERE pub_id =p1.pub_id
          AND type =
          'psychology')
| EXISTS s´utilise toujours dans le cadre d´une sous-requête; cette sous-requête ne renvoie pas de données, mais elle détermine l´existence des données, sur la base de tests booléens. L´exemple qui suit permet de renvoyer tous les éditeurs publiant des livres de psychologie.
Vérification de plage BETWEEN |
    WHERE [NOT] expression [NOT] BETWEEN expression AND expression
    SELECT *
    FROM titles
    WHERE ytd_sales BETWEEN 4000 AND 9000
| BETWEEN exécute une vérification de plage inclusive. Elle est identique à WHERE (expression>= x et expression<= y).
Vérification de plage IN |
    WHERE [NOT] expression [NOT] IN
    (value_list | subquery)
    SELECT *
    FROM stores
    WHERE state IN ('WA','IL','NY')

    SELECT *
    FROM stores
    WHERE stor_id IN
      (SELECT stor_id
      FROM sales
      WHERE ord_date LIKE
      'Oct%')
| IN renvoie soit un jeu de résultats correspondant à l´une des listes de valeurs, soit un jeu de résultats de la requête externe dont les valeurs correspondent à celles renvoyées par une sous-requête. La value_list ou la sous-requête doivent être placées entre parenthèses.
Vérification de plage SOME | ALL |
    WHERE [NOT] expression
    comparison_operator
    {[ANY | SOME] | ALL} (subquery)
    -- Pour dupliquer la fonctionnalité de IN
    SELECT au_lname,
           au_fname
    FROM   authors
    WHERE city = ANY
        (SELECT city
         FROM   publishers)
    -- Pour dupliquer la fonctionnalité de NOT IN
    SELECT au_lname,
           au_fname
    FROM authors
    WHERE city <> ALL
        (SELECT city
         FROM   publishers)
    /* to find the titles that got an
    advance larger than the minimum
    advance amount paid New Moon Books*/
    SELECT title
    FROM   titles
    WHERE  advance > ANY
        (SELECT  advance
         FROM publishers,
          titles
         WHERE titles.pub_id =
           publishers.pub_id
         AND pub_name = 'New
           Moon Books')
| ALL et SOME s´utilisent toujours dans le cadre d´une sous-requête, avec un opérateur de comparaison (<, >, <>, >= ou <=, par exemple). Une requête de type ALL évalue si la valeur TRUE ou FALSE s´applique lorsque toutes les valeurs récupérées par la sous-requête correspondent à la valeur de la clause WHERE (ou HAVING), ou bien lorsque la sous-requête ne renvoie aucune ligne de l´instruction externe.SOME possède la même fonctionnalité que EXISTS. Elle fonctionne de la même manière que la clause ALL, avec une différence: elle renvoie TRUE lorsque l´une des valeurs récupérées dans la sous-requête respecte le prédicat de comparaison inclus dans la clause WHERE de l´instruction externe.
Comme indiqué dans le Tableau 3.9, les caractères génériques peuvent accroître les options de recherche, notamment s´ils sont utilisés avec l´opérateur LIKE. Reportez-vous à la rubrique LIKE pour de plus amples informations sur les types d´opérations génériques.
Agrégats et clause GROUP BY
La clause GROUP BY (et la clause HAVING) sont uniquement requises dans les requêtes qui utilisent les fonctions agrégat (voir le début de ce chapitre). Les requêtes qui utilisent les fonctions agrégat proposent divers types d´informations récapitulatives. Les fonctions agrégat les plus courantes sont les suivantes:
AVG renvoie la moyenne de toutes les valeurs différentes de NULL dans la ou les colonnes spécifiées. COUNT compte le nombre d´occurrences de toutes les valeurs différentes de NULL dans la ou les colonnes spécifiées. COUNT DISTINCT compte le nombre d´occurrences de toutes les valeurs uniques différentes de NULL dans la ou les colonnes spécifiées. COUNT(*) compte tous les enregistrements de la table. MAX renvoie la plus élevée des valeurs différentes de NULL dans la ou les colonnes spécifiées. MIN renvoie la plus basse des valeurs différentes de NULL dans la ou les colonnes spécifiées. SUM effectue le total de toutes les valeurs différentes de NULL dans la ou les colonnes spécifiées.
La limitation des fonctions agrégat concerne les types de données auxquelles elles peuvent s´appliquer. Seules les fonctions COUNT et COUNT DISTINCT peuvent s´appliquer à une colonne contenant n´importe quel type de données. MIN et MAX s´appliquent aux colonnes numériques (quel qu´en soit le type), ainsi qu´aux colonnes de date et de caractères. Les fonctions SUM et AVG s´appliquent uniquement aux colonnes contenant des données de type numérique.
Si vous devez appliquer les fonctions agrégat à des colonnes contenant des valeurs null, utilisez la fonction ISNULL( ) dans SQL Server ou la fonction NVL dans Oracle pour attribuer une valeur aux colonnes null.
On appelle valeurs d´agrégat scalaire les requêtes qui ne renvoient qu´une seule valeur. La clause GROUP BY est inutile dans le cas des agrégats scalaires. Par exemple:
    --Requête
    SELECT AVG(price)
    FROM titles

    --Résultats
    14.77
On appelle agrégats vectoriels les requêtes qui renvoient à la fois des valeurs de colonne et des fonctions agrégat. Les agrégats vectoriels utilisent la clause GROUP BY et renvoient au moins une ligne. Il convient de suivre les règles suivantes lorsque vous utilisez la clause GROUP BY:
Respectez l´ordre de la clause GROUP BY &8212; après la clause WHERE et avant la clause ORDER BY. Incluez toutes les colonnes qui ne se rapportent pas aux agrégats dans la clause GROUP BY. N´utilisez aucun alias de colonne dans la clause GROUP BY (les alias de table sont autorisés).
Supposons que vous voulez connaître le nombre d´employés affectés aux divers postes de votre entreprise:
    --Requête
    SELECT   j.job_desc AS "Job Description",
             COUNT(e.job_id) AS "Nbr in Job"
    FROM     employee e
    JOIN     jobs j ON e.job_id = j.job_id
    GROUP BY j.job_desc

    --Résultats
    Job Description                                    Nbr in Job
    -------------------------------------------------- -----------
    Acquisitions Manager                               4
    Business Operations Manager                        1
    Chief Executive Officer                            1
    Chief Financial Officer                            1
    Designer                                           3
    Editor                                             3
    Managing Editor                                    4
    Marketing Manager                                  4
    Operations Manager                                 4
    Productions Manager                                4
    Public Relations Manager                           4
    Publisher                                          7
    Sales Representative                               3
Clause HAVING
La clause HAVING ajoute des conditions de recherche au résultat de la clause GROUP BY. Elle n´a aucune incidence sur les lignes qui servent au calcul des agrégats, mais elle affecte uniquement les lignes renvoyées par la requête.
Le fonctionnement de la clause HAVING est très similaire à celui de la clause WHERE. La clause HAVING utilise les mêmes conditions de recherche que la clause WHERE présentée dans le Tableau 3.9.
Par exemple, si vous voulez trouver les postes qui comptent plus de trois employés:
    --Requête
    SELECT   j.job_desc "Job Description",
             COUNT(e.job_id) "Nbr in Job"
    FROM     employee e
    JOIN     jobs j ON e.job_id = j.job_id
    GROUP BY j.job_desc
    HAVING   COUNT(e.job_id) > 3

    --Résultats
    Job Description                                    Nbr in Job
    -------------------------------------------------- -----------
    Acquisitions Manager                               4
    Managing Editor                                    4
    Marketing Manager                                  4
    Operations Manager                                 4
    Productions Manager                                4
    Public Relations Manager                           4
    Publisher                                          7
HAVING ne doit pas servir à supprimer les lignes que la clause WHERE permet de supprimer. Les conditions relatives à la clause HAVING doivent toujours inclure des valeurs d´agrégat.
Clause ORDER BY
Vous pouvez trier un jeu de résultats sur la base de la clause ORDER BY, conformément à l´ordre de tri défini pour la base de données. Le jeu de résultats peut ainsi être trié par ordre ascendant (ASC) ou descendant (DESC). (Le tri est ascendant par défaut.) Par exemple:
    --REQUÊTE
    SELECT   e.emp_id "Emp ID",
             rtrim(e.fname) || " " || rtrim(e.lname) "Name",
             j.job_desc "Job Desc"
    FROM     employee e,
             jobs j
    WHERE    e.job_id = j.job_id
      AND    j.job_desc = 'Acquisitions Manager'
    ORDER BY e.fname DESC,
             e.lname ASC

    --RESULTATS
    Emp ID    Name                           Job Desc
    --------- ------------------------------ --------------------
    M-R38834F Martine Rancé                  Acquisitions Manager
    MAS70474F Margaret Smith                 Acquisitions Manager
    KJJ92907F Karla Jablonski                Acquisitions Manager
    GHT50241M Gary Thomas                    Acquisitions Manager
Une fois restreint sur la base des conditions de recherche, le jeu de résultats fait l´objet d´un tri descendant par nom des auteurs. Si deux auteurs portent le même nom, le tri s´effectue sur la base de leur prénom, par ordre ascendant.
Les implémentations traitées dans le cadre de ce document permettent toutes d´utiliser les positions ordinales dans la clause ORDER_BY. Pour définir l´ordre du jeu de résultats, vous pouvez spécifier le nombre entier correspondant à la position de la colonne, plutôt que le nom ou l´alias de cette dernière. Par exemple, si vous voulez définir l´ordre suivant: au_id, au_ fname et au_lname:
    SELECT au_fname, au_lname, au_id
    FROM authors
    ORDER BY 3, 1, 2
En règle générale, utilisez la clause ORDER BY si vous voulez contrôler l´ordre du jeu de résultats de la requête. Si aucune clause ORDER BY n´est spécifiée, les implémentations renvoient les données, suivant l´ordre physique des données de la table ou l´ordre de tout index employé par la requête. Cette procédure peut entraîner des problèmes en cas de modification de l´index ou de l´ordre de tri physique. Pensez à spécifier explicitement l´ordre voulu.
Syntaxe et variations dans Microsoft SQL Server
Microsoft propose diverses variations de l´instruction SELECT, notamment des conseils d´optimisation, la clause INTO, la clause TOP, les variations GROUP BY, COMPUTE et WITH OPTIONS.
SELECT . . . INTO
    SELECT select_list
    INTO   new_table_name
    FROM   table_source
    WHERE  clause
La fonction SELECT . . . INTO est une option de commande quelque peu sujette à controverse propre à SQL Server. La commande SELECT . . . INTO permet de copier rapidement dans une nouvelle table les lignes et les colonnes extraites d´autres tables, sur la base d´une opération non inscrite.
L´exemple qui suit crée la table non_mgr_employees au moyen de SELECT . . . INTO. Cette table contient le numéro (emp_id), le prénom et le nom de tous les employés (à l´exception des cadres) figurant dans la table employee, assortis de leur description de poste, extraite de la table jobs:
    --REQUÊTE
    SELECT   e.emp_id "emp_id",
             convert(char(25),rtrim(e.fname) + " " + rtrim(e.lname)) "name",
             substring(j.job_desc,1,30) "job_desc"
    INTO     non_mgr_employee
    FROM     employee e
        JOIN jobs AS j ON e.job_id = j.job_id
    WHERE    j.job_desc NOT LIKE '%MANAG%'
    ORDER BY 2,3,1
Vous pouvez maintenant consulter la table non_mgr_employee que vous venez de créer et de charger. Une requête simple renvoie les données suivantes:
    --REQUÊTE
    SELECT   emp_id,
             name,
             job_desc
    FROM     non_mgr_emp
    ORDER BY 3,2,1

    --RESULTATS
    emp_id    name                      job_desc
    --------- ------------------------- ------------------------------
    PTC11962M Philip Cramer             Chief Executive Officer
    F-C16315M Francisco Chang           Chief Financial Officer
    <...edited for brevity...>
    PMA42628M Paolo Accorti             Sales Representative
    TPO55093M Timothy O'Rourke          Sales Representative
Vous devez uniquement utiliser SELECT . . . INTO dans un code de développement ou un autre code non lié à la production.
Clause TOP
La clause TOP respecte la syntaxe suivante:
    SELECT [TOP n [PERCENT] [WITH TIES]] select list
    FROM table_name
Cette commande indique que seules les n premières lignes doivent être récupérées dans le jeu de résultats de la requête. Si un pourcentage est également spécifié, seuls les n % des lignes seront récupérés. Le mot-clé WITH TIES s´utilise uniquement dans les requêtes qui incluent une clause ORDER BY. Cette variation indique que des lignes supplémentaires seront renvoyées depuis le jeu de résultats de base, en fonction de la valeur incluse dans la clause ORDER BY; ces lignes seront placées à la fin des lignes TOP.
Variations GROUP BY
GROUP BY prend en charge dans Microsoft SQL Server les variations ALL, WITH CUBE et WITH ROLLUP:
    [ GROUP BY [ALL] group_by_expression [,...n]
    [ WITH { CUBE | ROLLUP } ] ]
Avec la variation ALL, le jeu de résultats contient obligatoirement la totalité des groupes, même ceux dont les lignes ne correspondent à aucun des filtres de la clause WHERE. ALL est incompatible avec CUBE ou ROLLUP. CUBE indique qu´il faut extraire des lignes récapitulatives supplémentaires avec le jeu de résultats, pour toutes les combinaisons de groupe et de sous-groupe. Le fonctionnement de ROLLUP est similaire à celui de CUBE, sauf qu´il renvoie des groupes par ordre hiérarchique récapitulatif &8212; du niveau le plus bas au niveau le plus élevé du groupe.
Clause COMPUTE
La clause COMPUTE génère des totaux qui s´affichent sous la forme de colonnes récapitulatives supplémentaires à la fin du jeu de résultats. La clause COMPUTE BY génère des interruptions de contrôle et des sous-totaux dans le jeu de résultats. Vous pouvez inclure les clauses COMPUTE BY et COMPUTE dans la même requête:
    [ COMPUTE { { AVG | COUNT | MAX | MIN | STDEV | STDEVP |VAR | VARP | SUM }
    (expression) } [,...n]
    [ BY expression [,...n] ] ]
Les arguments (AVG, COUNT, MAX, MIN, STDEV, STDEVP, VAR, VARP, SUM ) spécifient l´agrégation que la clause COMPUTE doit exécuter. La valeur expression correspond normalement à un nom de colonne. La valeur BY expression correspond à une ou plusieurs des colonnes indiquées dans la clause ORDER BY des requêtes. COMPUTE figure dans une requête à la suite de la clause ORDER BY.
Clause OPTION
La clause OPTION est la dernière clause susceptible d´apparaître dans une requête Microsoft SQL Server. Elle indique qu´il convient d´utiliser une astuce de requête pour l´ensemble de la requête. Les astuces de requête représentent une méthode qui permet d´outrepasser le traitement par défaut d´une requête (cette méthode ne s´inscrit pas dans la norme ANSI). Les astuces de requête, de même que la syntaxe et l´utilisation complètes de la clause OPTION dépassent le cadre de cet ouvrage; vous pourrez toutefois trouver plus de détails dans la documentation SQL Server.
Syntaxes et variations dans MySQL
    SELECT [STRAIGHT_JOIN][SQL_SMALL_RESULT][SQL_BIG_RESULT][HIGH_PRIORITY]
    [INTO {OUTFILE | DUMPFILE} 'file_name' options]
    FROM...
    JOIN...
    [LIMIT [[offset_record,] number_of_rows]];
Les extensions MySQL incluent les modifications apportées au mot-clé SELECT par défaut, la prise en charge partielle de JOIN, la clause LIMIT et la clause PROCEDURE.
STRAIGHT_ JOIN est la première extension à la clause SELECT par défaut. STRAIGHT_JOIN force l´optimiseur à joindre les tables en suivant l´ordre exact dans lequel elles figurent dans la clause FROM. Il est possible d´utiliser SQL_SMALL_RESULT et SQL_BIG_RESULT lorsque la requête inclut une clause GROUP BY ou une clause DISTINCT, afin d´indiquer à l´optimiseur que le jeu de résultats attendu sera respectivement petit ou volumineux. Puisque MySQL crée une table temporaire si une requête possède une clause DISTINCT ou GROUP BY, ces clauses optionnelles indiquent à MySQL de créer une table temporaire rapide dans la mémoire (pour SQL_SMALL_RESULT) et une table temporaire plus lente sur disque (pour SQL_BIG_RESULT) en vue de traiter la table de travail. HIGH_PRIORITY confère à la requête un niveau de priorité plus élevé que celui des instructions qui servent à modifier les données de la table. Cette clause doit être réservée aux requêtes rapides spéciales. La clause LIMIT limite le nombre de lignes renvoyées par la requête, à partir de offset_record et returning number_of_rows. Si vous n´indiquez qu´un seul nombre entier, ce dernier sera considéré comme représentant le nombre d´enregistrements voulus, sur la base d´un décalage par défaut de 0.
La clause SELECT . . . INTO OUTFILE `file_name' inscrit le jeu de résultats de la requête dans un fichier placé sur le système de fichiers hôte. Le nom de fichier (file_name) doit déjà être défini. La syntaxe SELECT . . . INTO DUMPFILE inscrit une seule ligne continue de données, sans terminaisons de colonne ou de ligne, ni caractère d´échappement. Cette option s´utilise principalement avec les fichiers blob.
MySQL prend uniquement en charge la syntaxe JOIN des types suivants:
    [CROSS JOIN]
    INNER JOIN
    STRAIGHT_JOIN
    LEFT [OUTER] JOIN
    NATURAL LEFT [OUTER] JOIN
Syntaxe et variations dans Oracle
    SELECT {[ALL] [DISTINCT] | [UNIQUE]}...
    {columns_and_expressions_list} [,...n] AS alias
    [INTO {variable[,...n] | record}]
    FROM {[table_name [@database_link]| view_name | snapshot_name]
       | subquery [WITH {READ ONLY | CHECK OPTION [CONSTRAINT constraint_name]}]
       | TABLE {(nested_tbl_column)}
          [PARTITION {partition_name}]
          [SUBPARTITION {subpartition_name}
             [SAMPLE [BLOCK] [sample_percentage]}
    WHERE
    [[START WITH clause] CONNECT BY clause]
    GROUP BY...
    [ORDER BY... [NULLS FIRST | NULLS LAST] |
     FOR UPDATE [OF [schema.]table[,...n]] [NOWAIT] ]
Oracle autorise diverses extensions à la fonctionnalité ajoutée de prise en charge SELECT sur le serveur. Par exemple, puisque vous pouvez créer aussi bien des tables imbriquées que des tables partitionnées (voir CREATE TABLE), l´instruction SELECT autorise les requêtes provenant de ces structures nommées. (La clause PARTITION est inutile pour effectuer une requête à partir de la partition par défaut.)
La clause SAMPLE indique à Oracle de sélectionner les enregistrements dans un échantillon aléatoire provenant du jeu de résultats, plutôt que dans la table entière. La clause SAMPLE BLOCK indique à Oracle d´utiliser l´échantillonnage de bloc plutôt que l´échantillonnage de ligne. Le pourcentage d´échantillonnage, qui indique à Oracle le nombre total de blocs ou de lignes à inclure dans l´échantillon, peut avoir une valeur comprise entre 0,000001 et 99. L´échantillonnage s´applique uniquement aux requêtes portant sur une seule table.
La syntaxe SELECT . . . INTO, qui est réservée au code PL/SQL, permet à l´instruction SELECT d´attribuer des valeurs à des variables.
Vous devez utiliser la clause FROM TABLE nested_table_column pour la consultation d´une table imbriquée. La clause @database_link permet à la requête d´accéder aux tables stockées dans d´autres bases de données et sur d´autres serveurs, lorsque ces bases de données et ces serveurs ont été déclarés en tant que db_link. (Reportez-vous à la documentation de l'éditeur pour plus d'informations sur db_link.)
Les options NULL FIRST et NULL LAST de la clause ORDER BY indiquent que les lignes d´ordre du jeu de résultats qui possèdent une valeur de fin null doivent figurer respectivement en première ou en dernière place.
Oracle permet de spécifier les jeux de résultats par ordre hiérarchique. Ces requêtes hiérarchiques, telles qu´elles sont appelées, possèdent divers règles et comportements uniques. Reportez-vous à la documentation de l'éditeur pour des informations complètes sur l´utilisation de ce type de requête. La clause START WITH est capitale pour les requêtes hiérarchiques; elle spécifie les lignes racine d´une hiérarchie. La clause CONNECT BY décrit la relation qui lie les lignes parent et enfant de la hiérarchie.
La clause FOR UPDATE OF verrouille de façon exclusive la ligne renvoyée par la requête. Elle doit être immédiatement suivie d´une commande UPDATE . . . WHERE, COMMIT ou ROLLBACK. L´option NOWAIT indique à Oracle de ne pas attendre si un enregistrement est déjà verrouillé. A la place, la requête se termine et elle est immédiatement renvoyée à l´utilisateur.
Syntaxe et variations dans PostgreSQL
    SELECT...
    [INTO [TEMPORARY | TEMP] [TABLE] new_table_name]
    FROM...
    WHERE...
    [FOR UPDATE [OF class_name[,...n]]
    [LIMIT {count | ALL} [offset [,number_of_records]] ]
PostgreSQL permet de créer une nouvelle table sur la base de la syntaxe SELECT . . . INTO, qui est en gros identique à celle prise en charge par Microsoft SQL Server. PostgreSQL permet à la clause FOR UPDATE de verrouiller en mode exclusif les enregistrements sélectionnés par la requête. PostgreSQL prend également en charge la clause LIMIT, similaire à la clause MySQL du même nom, qui permet de limiter le nombre de lignes renvoyées par la requête.

SET CONNECTION |
L´instruction SET CONNECTION permet aux utilisateurs de basculer entre plusieurs connexions ouvertes sur un ou plusieurs serveurs de base de données.
Editeur | Commande
--- | ---
SQL Server | Prise en charge, avec des limites
MySQL | Non prise en charge
Oracle | Non prise en charge
PostgreSQL | Non prise en charge
Syntaxe SQL99 et description
    SET CONNECTION {DEFAULT | connection_name}
Cette commande ne met pas fin à une connexion. A la place, elle passe de la connexion en cours à la connexion nommée dans la commande, ou à la connexion en cours qui utilise la clause DEFAULT. Lors du basculement d´une connexion à l´autre, l´ancienne connexion devient inactive (sans aucune validation des modifications) et le nouvelle connexion devient active.
La commande CONNECT permet de créer une nouvelle connexion et la commande DISCONNECT, de mettre fin à une connexion.
Syntaxe et variations dans Microsoft SQL Server
Microsoft SQL Server prend uniquement en charge SET CONNECTION dans Embedded-SQL (ESQL), mais pas dans son outil de requête ponctuel, SQL Query Analyzer. Microsoft SQL Server prend en charge la syntaxe SQL99 complète.
Exemple
Ce programme ESQL complet dans SQL Server affiche CONNECT, DISCONNECT et SET CONNECTION:
    EXEC SQL CONNECT TO chicago.pubs AS chicago1 USER sa;
    EXEC SQL CONNECT TO new_york.pubs AS new_york1 USER read-only;
    // opens connections to the servers named "chicago" //
    //   and "new_york"//

    EXEC SQL SET CONNECTION chicago1;
    EXEC SQL SELECT name FROM employee INTO:name;
    // sets the chicago1 connection as active and performs work //
    //   within that session //

    EXEC SQL SET CONNECTION new_york1;
    EXEC SQL SELECT name FROM employee INTO:name;
    // sets the new_york1 connection as active and performs work //
    //   within that session //

    EXEC SQL DISCONNECT ALL;
    // Terminates all sessions.  You could alternately use two //
    //   DISCONNECT commands, one for each named connection. //

SET ROLE |
La commande SET ROLE active et désactive des rôles de sécurité spécifiques pour la session en cours. Les instructions CONNECT et CREATE ROLE permettent respectivement de créer des sessions et des rôles.
Editeur | Commande
--- | ---
SQL Server | Non prise en charge
MySQL | Non prise en charge
Oracle | Prise en charge, avec des variations
PostgreSQL | Non prise en charge
Syntaxe SQL99 et description
    SET ROLE {NONE | role_name}
L´instruction CONNECT ouvre cette session. Une fois qu´une session utilisateur est lancée, l´émission de l´instruction SET ROLE lui accorde un ensemble de privilèges associés à un rôle. La commande SET ROLE ne peut être émise qu´en dehors d´une transaction.
SET ROLE NONE attribue la session en cours à un rôle NULL.
Lorsqu´un rôle est attribué à la session utilisateur active, vous pouvez utiliser une chaîne de caractères, une variable de base de données, voire une fonction système, par exemple CURRENT_ROLE ou SYSTEM_ROLE. Dans ce cas, la valeur spécifiée doit être un nom de rôle valide.
Syntaxe et variations dans Oracle
    SET ROLE {role_name [IDENTIFIED BY password] [,...n]
    | [ALL [EXCEPT role_name [,...]]
    |  NONE;
Lorsqu´un utilisateur lance une connexion, Oracle lui attribue explicitement les privilèges qui lui servent de rôles. La commande SET ROLE vous permet de modifier le(s) rôle(s) sous le(s)quel(s) cette session fonctionne. Oracle utilise le paramètre d´initialisation MAX_ENABLED_ROLES pour contrôler le nombre maximal de rôles qu´il sera possible d´ouvrir en même temps.
Le paramètre role_name spécifié doit être un nom de rôle valide préalablement créé dans Oracle. Les rôles qui ne sont pas spécifiés ne pourront pas être utilisés dans le cadre de la session en cours. Si le paramètre role_name est doté d´un mot de passe, il doit être répertorié au moyen de la clause IDENTIFIED BY password. Pour identifier plusieurs rôles, séparez-les par une virgule.
L´instruction SET ROLE ALL active tous les rôles accordés à la session en cours, y compris les rôles accordés par l´intermédiaire d´autres rôles; la clause EXCEPT permet de dispenser d´autres rôles. Vous ne pouvez pas utiliser SET ROLE ALL lorsqu´un mot de passe est nécessaire. Seule l´instruction SET ROLE role_name IDENTIFIED BY password permet d´accéder aux rôles dotés d´un mot de passe.
L´instruction SET ROLE NONE désactive tous les rôles, en particulier le rôle par défaut.
Exemples
L´exemple qui suit permet d´activer les rôles read_only et updater, respectivement identifiés par les mots de passe editor et red_marker, pour la session en cours:
    SET ROLE read_only IDENTIFIED BY editor, updater IDENTIFIED BY red_marker;
L´exemple qui suit permet d´activer tous les rôles, à l´exception du rôle read_write :
    SET ROLE ALL EXCEPT read_write;

SET TIME ZONE |
L´instruction SET TIME ZONE modifie le fuseau horaire de la session en cours, s´il doit être différent du fuseau horaire par défaut.
Editeur | Commande
--- | ---
SQL Server | Non prise en charge
MySQL | Non prise en charge
Oracle | Non prise en charge
PostgreSQL | Prise en charge, avec des variations
Syntaxe SQL99 et description
    SET TIME ZONE {LOCAL | INTERVAL {+ | -}'00:00' HOUR TO MINUTE}
A l´instar de la plupart des commandes SET, SET TIME ZONE ne peut être exécutée qu´en dehors d´une transaction explicite. La clause LOCAL substitue aux valeurs d´heure de la session en cours celles du fuseau horaire par défaut sur le serveur. Sinon, une valeur d´intervalle peut être définie pour augmenter (+) ou réduire (-) l´heure par défaut.
Syntaxe et variations dans PostgreSQL
    SET TIME ZONE {'timezone' | LOCAL | DEFAULT
    | INTERVAL {+ | -}'00:00' HOUR TO MINUTE};
PostgreSQL permet d´attribuer à l´heure d´une session la valeur par défaut définie sur le serveur, au moyen de la clause LOCAL ou DEFAULT.
La valeur spécifiée pour le fuseau horaire dépend du système d´exploitation utilisé. Par exemple, `PST8PDT' est un fuseau horaire valide pour la Californie sur les systèmes Linux, alors que `Europe/Rome' est un fuseau horaire approprié pour l´Italie sur divers systèmes, dont Linux. Si le fuseau horaire est incorrect, la commande utilise comme fuseau horaire le méridien de Greenwich (GMT).
Le fuseau horaire peut également être défini comme un intervalle du fuseau horaire du serveur par défaut.
Exemples
L´exemple qui suit avance le fuseau horaire de trois heures sur le fuseau horaire par défaut actuel:
    SET TIME ZONE INTERVAL +'03:00' HOUR TO MINUTE;
Ensuite, l´heure actuelle de la session en cours est reculée de quatre heures et demie:
    SET TIME ZONE INTERVAL -'04:30' HOUR TO MINUTE;
Enfin, l´heure par défaut est rétablie pour la session en cours:
    SET TIME ZONE LOCAL;

SET TRANSACTION |
L´instruction SET TRANSACTION contrôle les diverses caractéristiques des modifications de données, par exemple l´accès en lecture/écriture ou son niveau d'isolation.
Editeur | Commande
--- | ---
SQL Server | Prise en charge, avec des variations
MySQL | Non prise en charge
Oracle | Prise en charge, avec des limites
PostgreSQL | Prise en charge
Syntaxe SQL99 et description
    SET [LOCAL] TRANSACTION { {READ ONLY | READ WRITE}[,...]
    | ISOLATION LEVEL
      {READ COMMITTED
      | READ UNCOMMITTED
      | REPEATABLE READ
      | SERIALIZABLE}[,...]
    | DIAGNOSTIC SIZE INT};
Lorsqu´elle est émise, cette commande est extérieure au contexte d´une transaction, mais elle s´applique à la transaction valide suivante. Elle permet d´appliquer plusieurs options, qui sont séparées par une virgule.
Avec la commande LOCAL, les paramètres de la transaction s´appliquent uniquement au serveur. Sinon, ils s´appliquent, quel que soit le serveur sur lequel la transaction est exécutée. Cette option est une nouvelle fonctionnalité de SQL99.
Vous pouvez aussi définir une transaction comme READ ONLY ou READ WRITE. Suivie d´un nombre entier, la clause DIAGNOSTIC SIZE indique le nombre de messages d´erreur à capturer pour une transaction. L´instruction GET DIAGNOSTICS permet d´extraire cette information.
La clause ISOLATION LEVEL contrôle plusieurs comportements d´une transaction dans le cadre de transactions simultanées. Les niveaux d´isolation contrôlent le comportement des transactions pour les lectures de données modifiées (dirty reads), les lectures uniques (non-repeatable reads) et les enregistrements fantômes (phantom records):
Lectures de données modifiées (dirty reads) Surviennent lorsqu´une transaction lit les enregistrements modifiés d´une autre transaction avant que celle-ci ne soit terminée. Il devient donc possible de modifier les données d´un enregistrement qui n´a peut-être pas encore été validé dans la base de données. Lectures uniques (non-repeatable reads) Surviennent lorsqu´une transaction lit un enregistrement pendant qu´une autre transaction le modifie. La première transaction ne peut donc plus trouver cet enregistrement pour le relire. Enregistrements fantômes (phantom records) Surviennent si des données sont ajoutées ou modifiées pendant qu´une transaction lit un groupe d´enregistrements, ce qui augmente le nombre d´enregistrements correspondant à cette première transaction.
La configuration du niveau d´isolation a une incidence sur ces anomalies, comme décrit dans le Tableau 3.10.
Niveau d´isolation | Lectures de données modifiées (dirty reads) | Lectures uniques (non-repeatable reads) | Enregistrements fantômes (phantom records)
--- | --- | --- | ---
READ COMMITTED | Non | Oui | Oui
READ UNCOMMITTED | Oui | Oui | Oui
REPEATABLE READ | non | non | oui
SERIALIZABLE | Non | Non | Non
SERIALIZABLE correspond au niveau d´isolation par défaut dans SQL99. Les transactions READ WRITE ne peuvent pas être définies comme READ UNCOMMITTED.
Syntaxe et variations dans Microsoft SQL Server
    SET TRANSACTION ISOLATION LEVEL
    {READ COMMITTED
    | READ UNCOMMITTED
    | REPEATABLE READ
    | SERIALIZABLE}
READ COMMITTED correspond à la valeur par défaut dans SQL Server, alors que serializable correspond à la valeur par défaut dans SQL99. Le niveau d´isolation s´applique pendant toute la durée de la session, alors que dans SQL99, il s´applique à la seule transaction.
Syntaxe et variations dans Oracle SQL Server
    SET TRANSACTION READ ONLY;
Oracle ne prend pas en charge la syntaxe complète de l´instruction SET TRANSACTION, et son implémentation de READ ONLY est également différente. Oracle prend uniquement en charge READ COMMITTED et SERIALIZABLE. READ COMMITTED correspond au comportement par défaut. Dans Oracle, cette commande lance une transaction possédant le niveau d´isolation SERIALIZABLE. Oracle autorise uniquement l´utilisation des commandes SELECT lorsque les commandes suivantes sont configurées: READ ONLY, ALTER SESSION, ALTER SYSTEM, LOCK TABLE et SET ROLE.
Syntaxe et variations dans PostgreSQL
    SET TRANSACTION ISOLATION LEVEL {READ COMMITTED | SERIALIZABLE};
PostgreSQL ne prend pas en charge la syntaxe complète de l´instruction SET TRANSACTION. Dans PostgreSQL, SET TRANSACTION ISOLATION LEVEL READ COMMITTED spécifie les lignes en lecture seule de la transaction en cours, qui ont été validées avant le lancement de celle-ci. Il s´agit de la valeur par défaut. SERIALIZABLE, qui correspond au niveau d´isolation ANSI par défaut, spécifie les lignes en lecture seule de la transaction en cours, qui ont été validées avant l´exécution de la première modification de données pour le lot.

START TRANSACTION |
L´instruction START TRANSACTION, qui est une nouvelle fonctionnalité de SQL99, permet d´exécuter toutes les fonctions de SET TRANSACTION et de lancer une nouvelle transaction.
Editeur | Commande
--- | ---
SQL Server | Non prise en charge; voir BEGIN TRAN dans la suite de ce chapitre
MySQL | Non prise en charge
Oracle | Non prise en charge
PostgreSQL | Non prise en charge; voir BEGIN TRAN dans la suite de ce chapitre
Syntaxe SQL99 et description
    START TRANSACTION { {READ ONLY | READ WRITE}[,...]
    | ISOLATION LEVEL
      {READ COMMITTED
      | READ UNCOMMITTED
      | REPEATABLE READ
      | SERIALIZABLE}[,...]
    | DIAGNOSTIC SIZE INT};
La seule différence qui sépare SET et START est la suivante: l´instruction SET est extérieure à la transaction en cours, alors que l´instruction START est considérée comme la marque d´une nouvelle transaction.
BEGIN TRANSACTION
La commande BEGIN TRANSACTION propose des fonctionnalités similaires à celles de l´instruction START TRANSACTION. Microsoft SQL Server et PostgreSQL reconnaissent tous deux BEGIN TRANSACTION, même si leur syntaxe respective varie légèrement. Oracle prend en charge les transactions implicites, mais non les transactions explicites. MySQL ne prend absolument pas en charge les transactions atomiques. BEGIN TRANSACTION déclare une transaction explicite, mais sans configurer les niveaux d´isolation.
La syntaxe Microsoft SQL Server est la suivante:
    BEGIN TRAN[SACTION] [transaction_name | @transaction_variable
    [WITH MARK [ 'log_description' ] ] ]
Microsoft SQL Server permet d´attribuer un nom à une transaction ou de faire référence aux transactions au moyen d´une variable. Il ne permet pas de modifier ou de renforcer cette fonctionnalité. Dans le cas de transactions imbriquées, seule la paire BEGIN . . . COMMIT ou BEGIN . . . ROLLBACK parente doit faire référence au nom de la transaction (le cas échéant).
L´option WITH MARK consigne la transaction dans le journal des événements de SQL Server. Si vous spécifiez WITH MARK `log_description', vous pouvez ajouter une chaîne descriptive à l´élément qui sera consigné.
La syntaxe PostgreSQL est la suivante:
    BEGIN [ WORK | TRANSACTION ]
L´exécution de PostgreSQL s´effectue normalement en mode d´autovalidation, pour lequel chaque requête ou modification de données constitue sa propre transaction. PostgreSQL applique normalement une instruction COMMIT ou ROLLBACK implicite à la fin de la transaction. L´utilisation de l´instruction BEGIN permet de déclarer explicitement l´instruction COMMIT ou ROLLBACK suivante.
Pensez à inclure BEGIN dans une paire contenant COMMIT ou ROLLBACK. Sinon, le SGBD doit attendre de trouver COMMIT ou ROLLBACK pour terminer la ou les commandes. Ce processus est susceptible de générer des transactions gigantesques, dont les résultats sur les données seront imprévisibles.
Les transactions à codage manuel sont beaucoup plus rapides dans PostgreSQL que les transactions autovalidées. Vous devez régler SET TRANSACTION ISOLATION LEVEL sur SERIALIZABLE immédiatement après l´instruction BEGIN pour renforcer l´isolation de la transaction. On peut dénombrer diverses instructions de modification de données (INSERT, UPDATE, DELETE) dans un bloc BEGIN . . . COMMIT. Suivant qu´elle se solde par un succès ou par un échec, la commande COMMIT entraîne l´exécution de toutes les transactions ou d´aucune.
Exemple
Dans l´exemple qui suit, les trois instructions INSERT seront traitées dans le cadre d´une même transaction:
    BEGIN TRANSACTION
       INSERT INTO sales VALUES('7896','JR3435','Oct 28 2001',25,
       'Net 60','BU7832')

       INSERT INTO sales VALUES('7901','JR3435','Oct 28 2001',17,
       'Net 60','BU7832')

       INSERT INTO sales VALUES('7907','JR3435','Oct 28 2001',6,
       'Net 60','BU7832')

    COMMIT
    GO
Cependant, le groupe complet de transactions échoue si, par exemple, l´une des instructions INSERT comporte une limite de clé primaire.

TRUNCATE TABLE |
La commande TRUNCATE TABLE est une instruction non ANSI qui supprime toutes les lignes d´une table sans consigner les suppressions de lignes individuelles. Cette commande est très pratique dans la mesure où elle permet de supprimer rapidement tous les enregistrements d´une table sans modifier la structure de cette dernière, tout en occupant un espace extrêmement réduit dans les fichiers de reprise ou les journaux des transactions. Elle présente cependant un inconvénient de taille; il est impossible de récupérer ou de sauvegarder les informations, puisqu´elles n´ont pas été consignées.
Editeur | Commande
--- | ---
SQL Server | Prise en charge
MySQL | Non prise en charge
Oracle | Prise en charge
PostgreSQL | Prise en charge
Syntaxe SQL99 et description
    TRUNCATE TABLE name
L´instruction TRUNCATE TABLE a le même effet qu´une instruction DELETE sans clause WHERE; elles éliminent toutes les deux les lignes d´une table spécifique. Cependant, il existe deux différences de taille. TRUNCATE TABLE est plus rapide et elle n´est pas consignée; autrement dit, il n´existe aucune possibilité d´annulation en cas d´erreur.
En règle générale, TRUNCATE TABLE n´active pas les triggers et ne fonctionne pas si une table donnée contient des clés étrangères.
Exemple
L´exemple qui suit supprime toutes les données de la table publishers:
    TRUNCATE TABLE publishers
Syntaxe et variations dans Oracle
    TRUNCATE { CLUSTER [owner.]cluster
       | TABLE [owner.]table [{PRESERVE | PURGE} SNAPSHOT LOG]}
    [{DROP | REUSE} STORAGE]
Oracle permet de tronquer une table ou un index clusterisé (mais pas un cluster hash).
Si vous choisissez de tronquer une table, Oracle permet de conserver ou de purger, le cas échéant, le journal des instantanés défini pour la table. PRESERVE conserve le journal des instantanés lorsque la table master est tronquée, tandis que PURGE le vide.
Lorsque la clause DROP STORAGE est ajoutée, l´espace disque libéré par la suppression des lignes n´est plus alloué. Lorsque la clause REUSE STORAGE est ajoutée, l´espace disque qui était alloué à la table ou au cluster pour les lignes supprimées est conservé.
Remarque pour Microsoft SQL Server et PostgreSQL
Ces deux implémentations prennent en charge la syntaxe SQL99 par défaut.

UPDATE |
La commande UPDATE modifie les données d´une table.
Editeur | Commande
--- | ---
SQL Server | Prise en charge, avec des variations
MySQL | Prise en charge, avec des variations
Oracle | Prise en charge, avec des variations
PostgreSQL | Prise en charge
Syntaxe SQL99 et description
    UPDATE {table_name | view_name}
    SET {column_name | variable_name} = {DEFAULT | expression} [,...n]
    WHERE conditions
A l´instar d´une instruction DELETE, une commande UPDATE est rarement émise sans clause WHERE, puisque cette instruction affecte toutes les lignes de la table.
Il est recommandé d´émettre une commande SELECT au moyen de la même clause WHERE avant d´émettre l´instruction UPDATE à proprement parler. Cette procédure vérifie toutes les lignes du jeu de résultats avant d´exécuter l´instruction UPDATE. Les lignes renvoyées par la commande SELECT sont toutes modifiées par l´instruction UPDATE.
Exemples
Une instruction UPDATE de base sans clause WHERE est similaire à celle-ci:
    UPDATE authors
    SET contract = 0
Sans clause WHERE, l´état de contrat de tous les auteurs de la table authors est réglé sur (autrement dit, ils ne possèdent plus de contrat). De même, vous pouvez ajuster mathématiquement les valeurs au moyen d´une instruction UPDATE:
    UPDATE titles
    SET price = price * 1.1
Cette instruction UPDATE permet d´augmenter de 10% le prix de tous les livres.
L´ajout d´une clause WHERE à une instruction UPDATE permet d´apporter des modifications sélectives aux enregistrements:
    UPDATE titles
    SET    type  = 'pers_comp',
           price = (price * 1.15)
    WHERE  type  = 'popular_com'
Cette requête apporte deux modifications à tout enregistrement du type `popular_com'. Cette commande augmente les prix de 15% et passe leur type à `pers_comp'.
Il peut arriver que vous deviez mettre à jour les valeurs d´une table donnée sur la base des valeurs stockées dans une autre table. Par exemple, si vous voulez mettre à jour la date de publication de tous les titres écrits par un auteur donné, vous devez commencer par trouver cet auteur et répertorier la liste de ses titres par le biais de sous-requêtes:
    UPDATE titles
    SET    pubdate = 'Jan 01 2002'
    WHERE  title_id IN
        (SELECT title_id
         FROM   titleauthor
         WHERE  au_id IN
             (SELECT au_id
              FROM   authors
              WHERE  au_lname = 'White'))
Syntaxe et variations dans Microsoft
    UPDATE {table_name | view_name} [WITH (table_hint [,...n])]
    SET {column_name | variable_name} = {DEFAULT | expression | NULL} [,...n]
    [FROM {table [,...n]}]
    WHERE {conditions | CURRENT OF [GLOBAL] cursor_name}
    [OPTION (query_hint [,...n])]
Microsoft SQL Server peut mettre à jour les vues et les tables. Vous pouvez utiliser les clauses WITH table_hint et OPTION afin de déclarer les astuces de l´optimiseur pour les tables et les requêtes. Les astuces de l´optimiseur outrepassent la fonctionnalité par défaut de l´optimiseur de requêtes. Reportez-vous à la documentation de l'éditeur pour des informations complètes sur les astuces de l´optimiseur.
Microsoft SQL Server prend en charge la clause FROM dans une instruction UPDATE. Cette variation présente un avantage de taille: elle facilite grandement les jointures multitable. L´exemple suivant illustre des jointures de tables pour les deux styles de syntaxe:
    -- ANSI style
    UPDATE titles
    SET    pubdate = GETDATE(  )
    WHERE  title_id IN
        (SELECT title_id
         FROM   titleauthor
         WHERE  au_id IN
             (SELECT au_id
              FROM   authors
              WHERE  au_lname = 'White'))

    -- Style Microsoft Transact-SQL
    UPDATE  titles
    SET     pubdate = GETDATE(  )
    FROM    authors a,
            titleauthor t2
    WHERE   a.au_id     = t2.au_id
        AND t2.title_id = titles.title_id
        AND a.au_lname  = 'White'
L´exécution de la mise à jour sur la base d´une syntaxe Transact-SQL revient simplement à exécuter trois jointures de table (authors, titles et titleauthor). Cependant, pour effectuer la même opération sur la base d´un code conforme à ANSI, vous devez commencer par rechercher au_id dans author, puis le transmettre à la table titleauthors, dans laquelle vous devez identifier title_id avant de le transmettre à l´instruction de mise à jour principale.
Utilisée en combinaison avec un curseur, la clause WHERE CURRENT OF cursor_name indique à SQL Server de mettre uniquement à jour l´enregistrement sur lequel le curseur est actuellement positionné. Le curseur peut être global ou local, conformément à la désignation du mot-clé GLOBAL.
L´exemple qui suit met à jour la colonne state pour les 10 premiers auteurs de la table authors:
    UPDATE authors
    SET state = 'ZZ'
    FROM (SELECT TOP 10 * FROM authors ORDER BY au_lname) AS t1
    WHERE authors.au_id = t1.au_id
Syntaxes et variations dans MySQL
    UPDATE [LOW PRIORITY] table_name
    SET {column_name | variable_name} = {DEFAULT | expression}
    WHERE conditions
    [LIMIT integer]
MySQL prend en charge la norme SQL99, avec deux variations: la clause LOW PRIORITY et la clause LIMIT. La clause LOW_PRIORITY indique à MySQL de reporter l´exécution de la commande UPDATE jusqu´à ce que les autres clients aient fini de consulter la table. La clause LIMIT réduit l´action de UPDATE au nombre spécifique de lignes indiqué par un nombre entier.
Syntaxe et variations dans Oracle
    UPDATE [schema.]{view_name | snapshot_name
       | table_name [@database_link]
          {[PARTITION partition_name] | [SUBPARTITION subpartition_name]}
       | subquery [WITH {[READ ONLY]
          | [CHECK OPTION [CONSTRAINT constraint_name] ]
    SET {column [,...] = {expression [,...n] | subquery} | VALUE value}
    WHERE conditions | CURRENT OF cursor_name}
    RETURNING expression [,...n] INTO variable [,...n];
L´implémentation dans Oracle de l´instruction UPDATE permet d´effectuer des mises à jour sur la base de vues, d´instantanés et de tables dans le cadre d´un schéma acceptable. La table à mettre à jour peut être locale ou elle peut avoir été proposée par @dblink. Les mises à jour interviennent toujours par rapport à une partition; cependant, la commande UPDATE prend en charge, le cas échéant, les mises à jour effectuées par rapport à une PARTITION ou une SUBPARTITION nommées.
La clause WITH devient disponible si vous effectuez la mise à jour en fonction d´une sous-requête. La clause WITH READ ONLY spécifie que la sous-requête ne peut pas faire l´objet d´une mise à jour. La clause WITH CHECK OPTION indique à Oracle d´abandonner toutes les modifications qui, apportées à la table actualisée, ne pourraient pas figurer dans le jeu de résultats de la sous-requête. La sous-clause CONSTRAINT indique à Oracle de limiter encore davantage les modifications sur la base d´une contrainte spécifique.
La clause SET VALUE permet à l´utilisateur de définir la valeur de ligne complète pour n´importe quelle valeur de type de données de table.
Dans Oracle, la clause WHERE CURRENT OF indique que la commande UPDATE doit être uniquement exécutée sur l´enregistrement actuel dans le contexte du curseur.
RETURNING récupère les lignes affectées par la commande. Quand elle est utilisée pour mettre à jour 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 mettre à jour plusieurs lignes, les valeurs des lignes sont stockées dans des tableaux attachés Le mot-clé INTO signifie que les valeurs mises à jour doivent être stockées dans la liste des variables.
Remarques pour PostgreSQL
PostgreSQL prend en charge la norme SQL99. Reportez-vous à la Section , plus avant dans ce chapitre, pour la description complète de la commande UPDATE .