Catálogos

ClickHouse

Con ClickHouse no hay pestañas Triggers ni Eventos, y una nota bajo las pestañas dice qué hace sus veces. Índices se llama Llaves: por tabla, la llave de ordenamiento, la de partición, la primaria si difiere, la de muestreo, los índices de salto con su tipo y su granularidad, y las proyecciones, sin cardinalidad ni Nuevo índice. Entre Vistas y Llaves está Vistas materializadas: la lista dice a qué escribe cada una —Interna, si el destino lo creó el servidor— y cuándo se refresca, y debajo va la ficha de la elegida: de qué tabla lee, a qué tabla escribe y con qué nombre consultarla, cuánto ocupa el destino y cuántas filas tiene, cuándo se escribió la última fila y, si se refresca sola, su programación, su estado y el último y el próximo refresco, con la zona escrita. Rutinas lista las funciones del usuario, que son lambdas y se crean y se editan desde aquí.

Oracle

Con Oracle el selector lista esquemas: los que tienen algún objeto que tu cuenta puede ver, más el tuyo aunque esté vacío, también los de Oracle (SYS, MDSYS…). Tablas enseña las del usuario —sin las internas de un índice espacial ni de una vista materializada—, con las filas de la última estadística (NUM_ROWS) y los tipos como los escribe Oracle (NUMBER(10,0), VARCHAR2(100 CHAR)). Las materializadas tienen su pestaña, Vistas materializadas: la tabla que guarda sus filas, de qué tablas lee, cuándo y cómo se actualiza, la última actualización y si está al día, con Actualizar ahora. Rutinas lista procedimientos, funciones y paquetes —con su especificación y su cuerpo en el panel de DDL— y pone INVALID detrás del tipo del que no compila; Triggers pone DISABLED detrás del que está desactivado. En Índices, uno por función enseña su expresión, y uno de dominio o anómalo, su tipo (DOMAIN · MDSYS.SPATIAL_INDEX_V2, NORMAL · INVISIBLE, UNUSABLE). Hay una pestaña más, Secuencias, con mínimo, máximo, paso, ciclo, caché y Siguiente en disco: el siguiente número que el servidor escribirá, no el último que entregó, que con caché puede ir hasta un bloque por detrás. Eventos lista los trabajos de DBMS_SCHEDULER del esquema.

SQL Server

Con SQL Server, entre Vistas e Índices está Vistas indexadas: las vistas con un índice agrupado único, que guardan sus filas en él. La ficha de la elegida dice en qué índice, cuánto ocupa, cuántas filas tiene y de qué tablas lee, y su DDL lleva los índices detrás; en Vistas ya no salen, aunque el árbol del editor, el respaldo y el comparador las siguen tratando como vistas. Secuencias lista las del esquema con mínimo, máximo, paso, ciclo, caché y Último entregado: el último número que dio NEXT VALUE FOR.

Oracle

Con Oracle el panel enseña lo que escribe el servidor con DBMS_METADATA.GET_DDL: nombres citados y cualificados, EDITIONABLE donde corresponde, la identidad entera y, en una tabla, sus índices, sus comentarios y sus claves foráneas al final, como ALTER TABLE. Si tu cuenta no puede leer el DDL de un objeto de otro esquema —le falta SELECT_CATALOG_ROLE—, sale un comentario que lo dice y no se ofrece Abrir en ItemEditor. Las secuencias también tienen Ver DDL.

MySQLMariaDBAurora

- Nuevo evento — en la pestaña Eventos, abre el editor de eventos del planificador

SQL Server

Con SQL Server, Eventos son los trabajos del Agent cuyo paso corre en esta base, listados en su dbo, y Nuevo evento crea uno. En Express, que no trae el Agent, la pestaña dice por qué está vacía.

PostgreSQL

Los eventos son los trabajos de la extensión pg_cron, y se listan en su esquema, cron: Nuevo evento los programa con cron.schedule. Sin la extensión, la pestaña Eventos dice qué falta.

ClickHouse

Con ClickHouse están Nueva vista y Nueva rutina, que crea una función lambda: no hay Nuevo índice —la pestaña es Llaves, y un índice de salto se añade desde el Constructor de tablas—, ni Nuevo trigger, ni pestaña Eventos.

Oracle

Con Oracle están Nueva vista, Nuevo índice, Nueva rutina —un procedimiento o una función—, Nuevo trigger y Nuevo evento, que es un trabajo de DBMS_SCHEDULER. Un paquete se edita, pero no se crea desde aquí.

TiDB

Con TiDB están Nueva vista y Nuevo índice. No hay Nueva rutina ni Nuevo trigger, ni pestaña Eventos: TiDB no tiene rutinas almacenadas, disparadores ni planificador de eventos, y Catálogos lo dice en una nota. Sus secuencias salen en la pestaña Secuencias, con su DDL.

MariaDB

Con MariaDB, rutinas, triggers e índices se reemplazan en una sentencia (CREATE OR REPLACE): si falla, el objeto que había sigue ahí.

Oracle

Con Oracle se editan los procedimientos, las funciones, los paquetes, los triggers y los trabajos de DBMS_SCHEDULER, que están en Eventos. Un trigger de varios eventos, con columnas de UPDATE OF, con un REFERENCING propio o COMPOUND, y una rutina cuya cabecera el formulario no sabe escribir, se abren pero no se guardan desde la hoja: Abrir en ItemEditor los lleva al editor SQL.

ClickHouse

Con ClickHouse, las funciones del usuario se editan con Editar (formulario visual), que abre el Editor de rutinas con sus parámetros y su expresión, y Abrir en ItemEditor lleva su DDL al editor SQL.

MySQLMariaDBAuroraTiDB

Una columna ENUM o SET recibe valores de su propia lista. Durante la carga se apaga la comprobación de claves foráneas, así que pueden quedar filas que apuntan a un padre que no existe: sirven para probar un JOIN sin pareja. Una fila con una clave repetida o un CHECK que no se cumple se descarta sin error, así que pueden entrar menos filas de las que pediste. Un valor fuera de rango no se descarta: entra recortado al límite del tipo —un TINYINT de 300 queda en 127— y deja un aviso.

PostgreSQL

Durante la carga no se disparan los triggers de la tabla, tampoco los que comprueban las claves foráneas, así que pueden quedar filas que apuntan a un padre que no existe. Una fila que repite una clave única se descarta sin error. Apagar los triggers pide superusuario: sin él, la carga sigue con las claves foráneas comprobadas, el mensaje final lo dice, y una tanda con un valor que no existe en la tabla padre se detiene con su aviso.

SQL ServerOracle

La comprobación de claves foráneas sigue encendida: una tanda con un valor que no existe en la tabla padre se detiene con su aviso, igual que una con una clave repetida.

MySQLMariaDBAuroraPostgreSQLOracleTiDB

OR REPLACE — CREATE OR REPLACE VIEW.

SQL Server

OR ALTER — CREATE OR ALTER VIEW.

MySQLMariaDBAurora

- Algoritmo — controla cómo procesa el servidor la vista:
- UNDEFINED (por defecto) — el servidor elige el algoritmo óptimo.
- MERGE — combina la consulta de la vista con la consulta externa. Más eficiente.
- TEMPTABLE — materializa la vista en una tabla temporal antes de aplicar filtros externos.
- SQL Security — define los privilegios con los que se ejecuta la vista:
- DEFINER (por defecto) — se ejecuta con los privilegios del usuario que la creó.
- INVOKER — se ejecuta con los privilegios del usuario que la consulta.

TiDB

TiDB acepta Algoritmo y SQL Security y los guarda en su SHOW CREATE VIEW. En TiDB ninguna vista admite escritura (IS_UPDATABLE es NO): las filas se cambian en sus tablas.

SQL ServerPostgreSQLOracle

No hay Algoritmo ni SQL Security: la hoja no los enseña.

SQL ServerOracle

WITH CHECK OPTION tiene una sola forma, la que describe CASCADED: elegir LOCAL escribe ésa, y la hoja lo dice.

TiDB

Con TiDB este editor no se abre: TiDB no tiene rutinas almacenadas (rechaza CREATE PROCEDURE y CREATE FUNCTION), y Catálogos no tiene pestaña Rutinas.

MySQLAurora

Dos sentencias, una detrás de otra: DROP PROCEDURE IF EXISTS y CREATE PROCEDURE (o DROP FUNCTION IF EXISTS y CREATE FUNCTION). MySQL no tiene CREATE OR REPLACE para rutinas, así que la que existe se borra primero: si la creación falla, ya no está.

MariaDB

Una sentencia: CREATE OR REPLACE PROCEDURE o CREATE OR REPLACE FUNCTION. Si falla, la rutina que había sigue ahí.

PostgreSQL

CREATE OR REPLACE PROCEDURE o CREATE OR REPLACE FUNCTION.

SQL Server

CREATE OR ALTER PROCEDURE o CREATE OR ALTER FUNCTION.

MySQLMariaDBAurora

- Determinista — escribe DETERMINISTIC si la rutina devuelve siempre el mismo resultado para los mismos parámetros de entrada. Importante para la replicación.
- Acceso a datos — declara el comportamiento de la rutina respecto a la base de datos:
- CONTAINS SQL — puede contener SQL pero no lee ni escribe datos.
- NO SQL — no contiene sentencias SQL.
- READS SQL DATA — lee datos pero no los modifica.
- MODIFIES SQL DATA — puede insertar, actualizar o eliminar datos.

PostgreSQL

Sólo Determinista, y sólo en funciones: escribe IMMUTABLE —la función devuelve siempre el mismo resultado para los mismos argumentos y no lee la base de datos—. Un procedimiento no tiene esa opción, y no hay Acceso a datos: PostgreSQL no tiene esa cláusula. Lenguaje elige el del cuerpo entre los que tiene el servidor: plpgsql por omisión, sql y los que haya instalados; al editar una rutina se conserva el suyo. Dos funciones con el mismo nombre y distintos argumentos —una sobrecarga— salen en la lista cada una con su firma, precio(integer) y precio(text), y se editan y se borran por separado.

SQL Server

No hay sección Opciones: SQL Server deduce por su cuenta si una función es determinista, y no tiene cláusula de acceso a datos. Un parámetro que no es IN se escribe @nombre tipo OUTPUT, y la @ se añade si no la pones.

Oracle

Con Oracle el editor escribe CREATE OR REPLACE PROCEDURE o FUNCTION con los parámetros como se escribieron —con su DEFAULT y su %TYPE—, RETURN y DETERMINISTIC, y conserva lo que la cabecera lleva y el formulario no enseña (AUTHID, RESULT_CACHE…). El cuerpo es lo que va tras el AS: las declaraciones y el bloque. Un paquete se edita entero: su especificación y su cuerpo, separados por una línea con /. Si el servidor lo guarda con errores de compilación, la hoja enseña cada línea de ALL_ERRORS y no lo da por creado.

ClickHouse

Con ClickHouse las rutinas son funciones lambda: el editor sólo ofrece FUNCTION, los parámetros llevan nombre y no tipo, no hay tipo de retorno ni Opciones, y el cuerpo es una expresión que nombra los parámetros (k * x + b). Escribe CREATE OR REPLACE FUNCTION nombre AS (x, k, b) -> k * x + b. La función es del servidor, no de una base: el nombre no lleva base delante. Al editarla, el cuerpo es la expresión tal como la guarda el servidor, con sus paréntesis.

TiDB

Con TiDB este editor no se abre: TiDB no tiene disparadores (rechaza CREATE TRIGGER), y Catálogos no tiene pestaña Triggers.

MySQLMariaDBAuroraPostgreSQL

- BEFORE — se ejecuta antes de la operación. Permite modificar los valores de NEW antes de escribirlos.
- AFTER — se ejecuta después de la operación.

SQL Server

- AFTER — se ejecuta después de la operación.
- INSTEAD OF — sustituye la operación por el código del trigger.
No hay BEFORE.

MySQLMariaDBAuroraPostgreSQL

El trigger salta una vez por fila: NEW.columna es el valor nuevo (en INSERT y UPDATE) y OLD.columna el anterior (en UPDATE y DELETE).

PostgreSQL

El código de un trigger vive en una función: Calíope crea la función <nombre>_fn con el cuerpo y el trigger que la llama, FOR EACH ROW. El cuerpo termina en RETURN: en un trigger BEFORE la fila que devuelve es la que se escribe, y NULL se salta la fila. El cuerpo de partida devuelve COALESCE(NEW, OLD), que vale para los tres eventos. Editar un trigger sin cambiarle el nombre lo reemplaza en una sentencia, CREATE OR REPLACE TRIGGER, desde PostgreSQL 14; antes, se borra y se vuelve a crear.

SQL Server

El trigger salta una vez por sentencia, no una vez por fila, y las filas nuevas y las anteriores están en las tablas inserted y deleted, no en NEW y OLD: el cuerpo de partida lo dice. Editar un trigger sin cambiarle el nombre lo reemplaza en una sentencia, CREATE OR ALTER TRIGGER, desde SQL Server 2016 SP1: no hay un momento sin trigger, y si el cuerpo nuevo no compila se queda el anterior; antes, se borra y se vuelve a crear.

Oracle

Con Oracle el momento es BEFORE, AFTER o INSTEAD OF —éste, sobre una vista—, y hay dos interruptores más: Por cada fila (FOR EACH ROW) y Habilitado (ENABLE o DISABLE). Guardar es CREATE OR REPLACE TRIGGER, y la condición WHEN que ya tuviera se conserva. Uno de varios eventos, con columnas de UPDATE OF, con un REFERENCING propio o COMPOUND se abre, pero no se guarda desde aquí. Si el servidor lo guarda con errores de compilación, la hoja enseña cada línea de ALL_ERRORS.

PostgreSQL

Con PostgreSQL el evento es un trabajo de pg_cron: el editor escribe cron.schedule(nombre, expresión, cuerpo), que con un nombre que ya existe lo sustituye, y DISABLE lo deja inactivo con cron.alter_job. Sólo hay recurrentes: cada N segundos (hasta 59), minutos u horas que dividan la hora y el día, y cada día, semana, mes o año, a la hora del comienzo en UTC. Una ejecución única o una fecha de fin no existen en pg_cron, y la vista previa SQL lo dice. Un trabajo con otra expresión cron se ve en su DDL, pero no abre el editor.

SQL Server

Con SQL Server el evento es un trabajo del Agent con un paso T-SQL que corre en esta base: el editor escribe sp_add_job, sp_add_jobstep, sp_add_jobschedule y sp_add_jobserver, y al editar, sp_update_job, sp_update_jobstep y sp_update_schedule, que conservan su historial. Los trabajos son del servidor, no de un esquema: se listan en el dbo de la base en la que corre su paso, y en otro esquema la pestaña dice dónde están. Un trabajo con varios pasos, o con una programación que el editor no escribe, se ve en su DDL pero no abre el editor. Express y Azure SQL Database no tienen Agent, y allí la pestaña no aparece.

Oracle

Con Oracle el evento es un trabajo de DBMS_SCHEDULER del esquema, un bloque PL/SQL: el editor escribe DBMS_SCHEDULER.CREATE_JOB con job_type => 'PLSQL_BLOCK', y al editar, SET_ATTRIBUTE, ENABLE y DISABLE, que conservan su historial; otro nombre suelta el trabajo y lo crea de nuevo. La programación es FREQ=…;INTERVAL=n, con las horas en UTC. Un trabajo con otro calendario, con un programa o que no es un bloque se ve en su DDL, pero no abre el editor. Crear exige el privilegio CREATE JOB.

MySQLMariaDBAurora

- FULLTEXT — búsqueda de texto completo. Solo para columnas CHAR, VARCHAR o TEXT y motor MyISAM/InnoDB (MySQL 5.6+).
- SPATIAL — datos geoespaciales. Solo para columnas de tipo espacial, con MyISAM o InnoDB (MySQL 5.7+, MariaDB 10.2+).

SQL Server

- SPATIAL — datos geoespaciales, en una columna geometry o geography de una tabla con clave primaria. Con geometry se escribe la Caja que acota los datos (xmin, ymin, xmax, ymax); con geography se deja vacía.

MySQLMariaDBAuroraPostgreSQL

- Método (para INDEX y UNIQUE):
- BTREE — árbol B, el método más común. Soporta comparaciones de rango, LIKE 'abc%', ORDER BY.
- HASH — tabla hash, solo soporta comparaciones de igualdad exacta.

MySQLMariaDBAurora

HASH sólo lo respeta el motor MEMORY.

PostgreSQL

Un índice UNIQUE no puede ser HASH, así que con UNIQUE el método es BTREE. Además de BTREE y HASH se ofrecen GIN —para jsonb, matrices y texto completo—, GIST y SPGIST —geometría y rangos— y BRIN, para tablas muy grandes ordenadas por inserción; al editar un índice se conserva el suyo. La casilla Construir sin bloquear escrituras (CONCURRENTLY) crea el índice sin cerrar la tabla a las escrituras, a cambio de tardar más.

SQL ServerOracle

No hay Método: CREATE INDEX no tiene cláusula USING.

SQL ServerPostgreSQLOracle

No hay índice por prefijo: se indexa la columna entera, y el DDL generado lo dice en un comentario.

ClickHouse

Con ClickHouse este editor no se abre: la pestaña es Llaves y no tiene Nuevo índice. Un índice de salto se añade o se quita en el Constructor de tablas, en su pestaña Índices.

Oracle

Con Oracle el tipo es INDEX, UNIQUE, FULLTEXT —un índice de Oracle Text, INDEXTYPE IS CTXSYS.CONTEXT— o SPATIAL —MDSYS.SPATIAL_INDEX_V2, que antes registra su fila de USER_SDO_GEOM_METADATA si falta, con el SRID de las geometrías que haya, o el 4326 en una tabla vacía—; los dos son de una columna, y sólo salen si el servidor trae Oracle Text y Spatial. El índice se crea en el esquema de su tabla. Borrar un índice que sostiene una restricción UNIQUE suelta la restricción, y con ella el índice.

TiDB

Con TiDB los tipos son INDEX y UNIQUE, y el método es BTREE: TiDB acepta FULLTEXT con un aviso sin crear el índice, y no tiene tipos espaciales que indexar.