Catalogues

ClickHouse

Avec ClickHouse, il n'y a pas d'onglets Déclencheurs ni Événements, et une note sous les onglets dit ce qui en tient lieu. Index s'appelle Clés : pour chaque table, la clé de tri, la clé de partition, la clé primaire si elle diffère, la clé d'échantillonnage, les index de saut avec leur type et leur granularité, et les projections, sans cardinalité ni Nouvel index. Entre Vues et Clés se trouve Vues matérialisées : la liste dit où écrit chacune —Interne, si la cible a été créée par le serveur— et quand elle se rafraîchit, et dessous vient la fiche de celle sélectionnée : de quelle table elle lit, dans quelle table elle écrit et sous quel nom l'interroger, la place qu'occupe la cible et son nombre de lignes, quand la dernière ligne a été écrite et, si elle se rafraîchit seule, sa programmation, son état et le dernier et le prochain rafraîchissement, avec le fuseau écrit. Routines liste les fonctions de l'utilisateur, qui sont des lambdas et se créent et se modifient d'ici.

Oracle

Avec Oracle le sélecteur liste des schémas : ceux qui ont un objet visible par votre compte, plus le vôtre même vide, ceux d’Oracle compris (SYS, MDSYS…). Tables montre celles de l’utilisateur —sans les tables internes d’un index spatial ni d’une vue matérialisée—, avec les lignes de la dernière statistique (NUM_ROWS) et les types tels qu’Oracle les écrit (NUMBER(10,0), VARCHAR2(100 CHAR)). Les vues matérialisées ont leur onglet, Vues matérialisées : la table qui stocke leurs lignes, les tables qu’elles lisent, quand et comment elles s’actualisent, la dernière actualisation et si elles sont à jour, avec Actualiser maintenant. Routines liste procédures, fonctions et packages —avec leur spécification et leur corps dans le panneau DDL— et met INVALID après le type de celle qui ne compile pas ; Déclencheurs met DISABLED après celui qui est désactivé. Dans Index, un index sur fonction montre son expression, et un index de domaine ou anormal, son type (DOMAIN · MDSYS.SPATIAL_INDEX_V2, NORMAL · INVISIBLE, UNUSABLE). Il y a un onglet de plus, Séquences, avec minimum, maximum, pas, cycle, cache et Suivant sur disque : le prochain numéro que le serveur écrira, pas le dernier qu’il a remis, qui avec un cache peut avoir jusqu’à un bloc de retard. Événements liste les tâches DBMS_SCHEDULER du schéma.

SQL Server

Avec SQL Server, entre Vues et Index se trouve Vues indexées : les vues dotées d’un index cluster unique, qui y stockent leurs lignes. La fiche de celle choisie indique quel index, sa taille, son nombre de lignes et les tables qu’elle lit, et son DDL porte les index à la suite ; elles n’apparaissent plus dans Vues, même si l’arbre de l’éditeur, la sauvegarde et le comparateur les traitent toujours comme des vues. Séquences liste celles du schéma avec minimum, maximum, pas, cycle, cache et Dernier délivré : le dernier nombre qu’a donné NEXT VALUE FOR.

Oracle

Avec Oracle le panneau montre ce que le serveur écrit avec DBMS_METADATA.GET_DDL : noms cités et qualifiés, EDITIONABLE là où il s’applique, l’identité entière et, pour une table, ses index, ses commentaires et ses clés étrangères à la fin, en ALTER TABLE. Si votre compte ne peut pas lire le DDL d’un objet d’un autre schéma —il lui manque SELECT_CATALOG_ROLE—, un commentaire le dit et Ouvrir dans ItemEditor n’est pas proposé. Les séquences ont aussi Voir DDL.

MySQLMariaDBAurora

- Nouvel événement — dans l'onglet Événements, ouvre l'éditeur d'événements du planificateur

SQL Server

Avec SQL Server, Événements sont les travaux de l’Agent dont l’étape s’exécute dans cette base, listés sous son dbo, et Nouvel événement en crée un. En Express, qui n’a pas d’Agent, l’onglet dit pourquoi il est vide.

PostgreSQL

Les événements sont les tâches de l’extension pg_cron, listées dans son schéma, cron : Nouvel événement les programme avec cron.schedule. Sans l’extension, l’onglet Événements dit ce qui manque.

ClickHouse

Avec ClickHouse, il y a Nouvelle vue et Nouvelle routine, qui crée une fonction lambda : ni Nouvel index —l'onglet est Clés, et un index de saut s'ajoute depuis le Constructeur de tables—, ni Nouveau déclencheur, ni onglet Événements.

Oracle

Avec Oracle, il y a Nouvelle vue, Nouvel index, Nouvelle routine —une procédure ou une fonction—, Nouveau trigger et Nouvel événement, qui est une tâche DBMS_SCHEDULER. Un package se modifie, mais ne se crée pas d’ici.

TiDB

Avec TiDB il y a Nouvelle vue et Nouvel index. Il n’y a ni Nouvelle routine, ni Nouveau déclencheur, ni onglet Événements : TiDB n’a ni routines stockées, ni déclencheurs, ni planificateur d’événements, et Catalogues le dit dans une note. Ses séquences apparaissent dans l’onglet Séquences, avec leur DDL.

MariaDB

Avec MariaDB, routines, déclencheurs et index sont remplacés en une seule instruction (CREATE OR REPLACE) : si elle échoue, l'objet qui existait est toujours là.

Oracle

Avec Oracle, on modifie les procédures, les fonctions, les packages, les triggers et les tâches DBMS_SCHEDULER, qui sont dans Événements. Un trigger à plusieurs événements, avec des colonnes UPDATE OF, son propre REFERENCING ou COMPOUND, et une routine dont le formulaire ne sait pas écrire l’en-tête, s’ouvrent mais ne s’enregistrent pas depuis la feuille : Ouvrir dans ItemEditor les emmène dans l’éditeur SQL.

ClickHouse

Avec ClickHouse, les fonctions utilisateur se modifient avec Modifier (formulaire visuel), qui ouvre l’éditeur de routines avec leurs paramètres et leur expression, et Ouvrir dans ItemEditor emmène leur DDL dans l’éditeur SQL.

MySQLMariaDBAuroraTiDB

Une colonne ENUM ou SET reçoit des valeurs de sa propre liste. Pendant le chargement, la vérification des clés étrangères est désactivée : il peut donc rester des lignes qui pointent vers un parent inexistant, utiles pour tester un JOIN sans correspondance. Une ligne avec une clé répétée ou un CHECK non respecté est écartée sans erreur, si bien que moins de lignes que demandé peuvent être insérées. Une valeur hors limites n'est pas écartée : elle entre tronquée à la limite du type — un TINYINT de 300 devient 127 — et laisse un avertissement.

PostgreSQL

Pendant le chargement, les triggers de la table ne se déclenchent pas, y compris ceux qui vérifient les clés étrangères : il peut donc rester des lignes qui pointent vers un parent inexistant. Une ligne qui répète une clé unique est écartée sans erreur. Désactiver les triggers exige un superutilisateur : sans lui, le chargement continue avec les clés étrangères vérifiées, le message final le dit, et un lot avec une valeur absente de la table parente s'arrête avec son avertissement.

SQL ServerOracle

La vérification des clés étrangères reste active : un lot contenant une valeur absente de la table parente s'arrête avec son avertissement, de même qu'un lot avec une clé répétée.

MySQLMariaDBAuroraPostgreSQLOracleTiDB

OR REPLACE — CREATE OR REPLACE VIEW.

SQL Server

OR ALTER — CREATE OR ALTER VIEW.

MySQLMariaDBAurora

- Algorithme — contrôle la façon dont le serveur traite la vue :
- UNDEFINED (par défaut) — le serveur choisit l'algorithme optimal.
- MERGE — fusionne la requête de la vue avec la requête externe. Plus efficace.
- TEMPTABLE — matérialise la vue dans une table temporaire avant d'appliquer les filtres externes.
- SQL Security — définit les privilèges avec lesquels la vue s'exécute :
- DEFINER (par défaut) — s'exécute avec les privilèges de l'utilisateur qui l'a créée.
- INVOKER — s'exécute avec les privilèges de l'utilisateur qui l'interroge.

TiDB

TiDB accepte Algorithme et SQL Security et les conserve dans son SHOW CREATE VIEW. Aucune vue TiDB n’accepte l’écriture (IS_UPDATABLE vaut NO) : les lignes se modifient dans ses tables.

SQL ServerPostgreSQLOracle

Il n'y a ni Algorithme ni SQL Security : la feuille ne les affiche pas.

SQL ServerOracle

WITH CHECK OPTION n'a qu'une forme, celle que décrit CASCADED : choisir LOCAL écrit celle-là, et la feuille le dit.

TiDB

Avec TiDB cet éditeur ne s’ouvre pas : TiDB n’a pas de routines stockées (il refuse CREATE PROCEDURE et CREATE FUNCTION), et Catalogues n’a pas d’onglet Routines.

MySQLAurora

Deux instructions, exécutées l'une après l'autre : DROP PROCEDURE IF EXISTS et CREATE PROCEDURE (ou DROP FUNCTION IF EXISTS et CREATE FUNCTION). MySQL n'a pas de CREATE OR REPLACE pour les routines, donc celle qui existe est d'abord supprimée : si la création échoue, elle n'est plus là.

MariaDB

Une seule instruction : CREATE OR REPLACE PROCEDURE ou CREATE OR REPLACE FUNCTION. Si elle échoue, la routine qui existait est toujours là.

PostgreSQL

CREATE OR REPLACE PROCEDURE ou CREATE OR REPLACE FUNCTION.

SQL Server

CREATE OR ALTER PROCEDURE ou CREATE OR ALTER FUNCTION.

MySQLMariaDBAurora

- Déterministe — écrit DETERMINISTIC si la routine retourne toujours le même résultat pour les mêmes paramètres d'entrée. Important pour la réplication.
- Accès aux données — déclare le comportement de la routine vis-à-vis de la base de données :
- CONTAINS SQL — peut contenir du SQL mais ne lit ni n'écrit de données.
- NO SQL — ne contient pas d'instructions SQL.
- READS SQL DATA — lit des données mais ne les modifie pas.
- MODIFIES SQL DATA — peut insérer, mettre à jour ou supprimer des données.

PostgreSQL

Seulement Déterministe, et seulement pour les fonctions : il écrit IMMUTABLE — la fonction retourne toujours le même résultat pour les mêmes arguments et ne lit pas la base de données. Une procédure n'a pas cette option, et il n'y a pas d'Accès aux données : PostgreSQL n'a pas cette clause. Langage choisit celui du corps parmi ceux du serveur : plpgsql par défaut, sql et ceux qui sont installés ; modifier une routine conserve le sien. Deux fonctions de même nom aux arguments différents —une surcharge— apparaissent dans la liste chacune avec sa signature, precio(integer) et precio(text), et se modifient et se suppriment séparément.

SQL Server

Il n'y a pas de section Options : SQL Server déduit lui-même si une fonction est déterministe, et n'a pas de clause d'accès aux données. Un paramètre qui n'est pas IN s'écrit @nom type OUTPUT, et le @ est ajouté si vous l'omettez.

Oracle

Avec Oracle, l’éditeur écrit CREATE OR REPLACE PROCEDURE ou FUNCTION avec les paramètres tels qu’ils ont été écrits —avec leur DEFAULT et leur %TYPE—, RETURN et DETERMINISTIC, et garde ce que l’en-tête porte et que le formulaire ne montre pas (AUTHID, RESULT_CACHE…). Le corps est ce qui suit AS : les déclarations et le bloc. Un package se modifie en entier : sa spécification et son corps, séparés par une ligne avec /. Si le serveur l’enregistre avec des erreurs de compilation, la feuille montre chaque ligne de ALL_ERRORS et ne le donne pas pour créé.

ClickHouse

Avec ClickHouse, les routines sont des fonctions lambda : l'éditeur ne propose que FUNCTION, les paramètres ont un nom et pas de type, il n'y a ni type de retour ni Options, et le corps est une expression qui nomme les paramètres (k * x + b). Il écrit CREATE OR REPLACE FUNCTION nom AS (x, k, b) -> k * x + b. La fonction appartient au serveur, pas à une base : son nom ne porte pas de base devant. Quand on la modifie, le corps est l'expression telle que le serveur la garde, avec ses parenthèses.

TiDB

Avec TiDB cet éditeur ne s’ouvre pas : TiDB n’a pas de déclencheurs (il refuse CREATE TRIGGER), et Catalogues n’a pas d’onglet Déclencheurs.

MySQLMariaDBAuroraPostgreSQL

- BEFORE — s'exécute avant l'opération. Permet de modifier les valeurs de NEW avant qu'elles soient écrites.
- AFTER — s'exécute après l'opération.

SQL Server

- AFTER — s'exécute après l'opération.
- INSTEAD OF — remplace l'opération par le code du déclencheur.
Il n'y a pas de BEFORE.

MySQLMariaDBAuroraPostgreSQL

Le déclencheur se déclenche une fois par ligne : NEW.colonne est la nouvelle valeur (dans INSERT et UPDATE) et OLD.colonne la précédente (dans UPDATE et DELETE).

PostgreSQL

Le code d'un déclencheur vit dans une fonction : Calíope crée la fonction <nom>_fn avec le corps et le déclencheur qui l'appelle, FOR EACH ROW. Le corps se termine par RETURN : dans un déclencheur BEFORE, la ligne qu'il renvoie est celle qui est écrite, et NULL ignore la ligne. Le corps de départ renvoie COALESCE(NEW, OLD), qui convient aux trois événements. Modifier un déclencheur sans le renommer le remplace en une seule instruction, CREATE OR REPLACE TRIGGER, depuis PostgreSQL 14 ; avant, il est supprimé puis recréé.

SQL Server

Le déclencheur se déclenche une fois par instruction, pas une fois par ligne, et les nouvelles lignes et les précédentes sont dans les tables inserted et deleted, pas dans NEW et OLD : le corps de départ le dit. Modifier un déclencheur sans le renommer le remplace en une seule instruction, CREATE OR ALTER TRIGGER, depuis SQL Server 2016 SP1 : il n’y a aucun instant sans déclencheur, et si le nouveau corps ne compile pas, l’ancien reste ; avant, il est supprimé puis recréé.

Oracle

Avec Oracle, le moment est BEFORE, AFTER ou INSTEAD OF —ce dernier, sur une vue—, et il y a deux interrupteurs de plus : Pour chaque ligne (FOR EACH ROW) et Activé (ENABLE ou DISABLE). Enregistrer, c’est CREATE OR REPLACE TRIGGER, et la condition WHEN qu’il avait est conservée. Un trigger à plusieurs événements, avec des colonnes UPDATE OF, son propre REFERENCING ou COMPOUND s’ouvre, mais ne s’enregistre pas d’ici. Si le serveur l’enregistre avec des erreurs de compilation, la feuille montre chaque ligne de ALL_ERRORS.

PostgreSQL

Avec PostgreSQL, l’événement est une tâche de pg_cron : l’éditeur écrit cron.schedule(nom, expression, corps), qui remplace une tâche qui porte déjà ce nom, et DISABLE la laisse inactive avec cron.alter_job. Il n’y a que des récurrents : toutes les N secondes (jusqu’à 59), minutes ou heures qui divisent l’heure et le jour, et chaque jour, semaine, mois ou année, à l’heure du début en UTC. Une exécution unique ou une date de fin n’existent pas dans pg_cron, et l’aperçu SQL le dit. Une tâche avec une autre expression cron se voit dans son DDL, mais n’ouvre pas l’éditeur.

SQL Server

Avec SQL Server, l’événement est un travail de l’Agent avec une étape T-SQL qui s’exécute dans cette base : l’éditeur écrit sp_add_job, sp_add_jobstep, sp_add_jobschedule et sp_add_jobserver, et à la modification, sp_update_job, sp_update_jobstep et sp_update_schedule, qui conservent son historique. Les travaux appartiennent au serveur, pas à un schéma : ils sont listés dans le dbo de la base où s’exécute leur étape, et dans un autre schéma l’onglet dit où ils sont. Un travail à plusieurs étapes, ou avec une planification que l’éditeur n’écrit pas, se voit dans son DDL mais n’ouvre pas l’éditeur. Express et Azure SQL Database n’ont pas d’Agent, et là l’onglet n’apparaît pas.

Oracle

Avec Oracle, l’événement est une tâche DBMS_SCHEDULER du schéma, un bloc PL/SQL : l’éditeur écrit DBMS_SCHEDULER.CREATE_JOB avec job_type => 'PLSQL_BLOCK', et en modification, SET_ATTRIBUTE, ENABLE et DISABLE, qui gardent son historique ; un autre nom supprime la tâche et la recrée. La planification est FREQ=…;INTERVAL=n, avec les heures en UTC. Une tâche avec un autre calendrier, avec un programme ou qui n’est pas un bloc se voit dans son DDL, mais n’ouvre pas l’éditeur. Créer exige le privilège CREATE JOB.

MySQLMariaDBAurora

- FULLTEXT — recherche en texte intégral. Uniquement pour les colonnes CHAR, VARCHAR ou TEXT et le moteur MyISAM/InnoDB (MySQL 5.6+).
- SPATIAL — données géospatiales. Uniquement pour les colonnes de type spatial, avec MyISAM ou InnoDB (MySQL 5.7+, MariaDB 10.2+).

SQL Server

- SPATIAL — données géospatiales, sur une colonne geometry ou geography d’une table avec clé primaire. Pour geometry, on écrit la Boîte qui borne les données (xmin, ymin, xmax, ymax) ; pour geography, on la laisse vide.

MySQLMariaDBAuroraPostgreSQL

- Méthode (pour INDEX et UNIQUE) :
- BTREE — arbre B, la méthode la plus courante. Prend en charge les comparaisons de plages, LIKE 'abc%', ORDER BY.
- HASH — table de hachage, prend uniquement en charge les comparaisons d'égalité exacte.

MySQLMariaDBAurora

Seul le moteur MEMORY respecte HASH.

PostgreSQL

Un index UNIQUE ne peut pas être HASH, donc avec UNIQUE la méthode est BTREE. En plus de BTREE et HASH, il propose GIN —pour jsonb, les tableaux et le texte intégral—, GIST et SPGIST —géométrie et intervalles— et BRIN, pour les très grandes tables ordonnées par insertion ; modifier un index conserve le sien. La case Construire sans bloquer les écritures (CONCURRENTLY) crée l’index sans fermer la table aux écritures, au prix d’une construction plus longue.

SQL ServerOracle

Il n'y a pas de Méthode : CREATE INDEX n'a pas de clause USING.

SQL ServerPostgreSQLOracle

Il n'y a pas d'index par préfixe : la colonne entière est indexée, et le DDL généré le dit dans un commentaire.

ClickHouse

Avec ClickHouse, cet éditeur ne s'ouvre pas : l'onglet est Clés et il n'a pas de Nouvel index. Un index de saut s'ajoute ou se retire dans le Constructeur de tables, dans son onglet Index.

Oracle

Avec Oracle le type est INDEX, UNIQUE, FULLTEXT —un index Oracle Text, INDEXTYPE IS CTXSYS.CONTEXT— ou SPATIAL —MDSYS.SPATIAL_INDEX_V2, qui enregistre d’abord sa ligne de USER_SDO_GEOM_METADATA si elle manque, avec le SRID des géométries existantes, ou 4326 sur une table vide— ; les deux portent sur une colonne, et n’apparaissent que si le serveur a Oracle Text et Spatial. L’index se crée dans le schéma de sa table. Supprimer un index qui soutient une contrainte UNIQUE supprime la contrainte, et l’index avec elle.

TiDB

Avec TiDB les types sont INDEX et UNIQUE, et la méthode est BTREE : TiDB accepte FULLTEXT avec un avertissement sans créer l’index, et n’a pas de types spatiaux à indexer.