Manual de usuario

Schevo es un modelador de bases de datos PostgreSQL, MySQL, MariaDB y SQL Server que guarda el modelo en un formato pensado para Git: cada tabla en su propio fichero JSON, con una salida estable que se puede revisar y mezclar como cualquier otro código.

Primeros pasos

1. Importa tu esquema: Archivo > Importar SQL… (Ctrl+I) y elige el script de creación de la base de datos. Schevo dibuja el diagrama agrupando las tablas por prefijo (cat_, ped_…).
2. Guarda el modelo (Ctrl+S) en una carpeta de tu repositorio, por ejemplo db-model/. Si el SQL venía de un fichero, queda asociado al modelo y se regenera cada vez que guardes.
3. Trabaja y guarda: solo se reescriben los ficheros que cambian.

La primera vez que abres Schevo se carga una tienda online de ejemplo para que puedas probarlo todo. Después, al arrancar se reabre el último modelo; los anteriores están en Archivo > Abrir reciente.

Puedes tener varios modelos abiertos a la vez. Si la ventana ya tiene un modelo, al abrir, crear o importar otro Schevo pregunta si lo abre en una ventana nueva o en esta ventana; si ese modelo ya está abierto en otra ventana, la trae al frente. Archivo > Cerrar ventana (Ctrl+W) cierra solo la ventana actual y Archivo > Salir, todas.

La carpeta del modelo

db-model/
  project.json                     nombre, esquema por defecto, ruta del SQL, fin de línea, reglas de nombres
  tables/public.cat_producto.json  una tabla por fichero: columnas, PK, FK, índices, posición y color
  extra.sql                        sentencias que no se dibujan (secuencias, vistas, funciones…), si las hay
  diagram.json                     zonas y notas del diagrama, si las hay

Importar desde una base de datos

Si no tienes el script de creación, Archivo > Importar desde base de datos… lee el esquema directamente de una base de datos PostgreSQL (versión 10 o superior); para MySQL, MariaDB y SQL Server, consulta sus apartados. Indica el servidor, el puerto, la base de datos, el usuario y la contraseña, y marca Usar SSL si el servidor lo exige. Probar conexión comprueba los datos y muestra los esquemas para que elijas cuáles leer; si no eliges, se leen todos los de usuario (nunca pg_catalog ni information_schema).

El resultado es el mismo modelo que daría importar el script de creación de esa base de datos: tablas, columnas, claves primarias, FK (con sus acciones), UNIQUE, CHECK, índices y comentarios. Las columnas con secuencia propia pasan a SERIAL/BIGSERIAL, y las IDENTITY son columnas de identidad, con las opciones de su secuencia. Lo que no se dibuja (esquemas, extensiones, tipos ENUM, dominios, secuencias, funciones, vistas, triggers, índices sobre expresiones o parciales y restricciones EXCLUDE) se conserva en Proyecto > Sentencias SQL adicionales. No se leen tipos compuestos ni de rango, reglas, políticas, permisos ni comentarios de otros objetos.

La conexión es de solo lectura y solo consulta el catálogo. Schevo recuerda el servidor, el puerto, la base de datos y el usuario, pero nunca guarda la contraseña. PostgreSQL reescribe a su manera los DEFAULT y CHECK (por ejemplo, BETWEEN pasa a >= … AND <= … y IN (…) a = ANY (ARRAY[…])); Schevo deshace los cambios más habituales en el texto, y al comparar o generar migraciones considera iguales las expresiones equivalentes, así que la base de datos y el modelo importado de su script no muestran diferencias.

La base de datos también puede ser la otra versión al comparar y el estado inicial de un script de migración: elige Base de datos y pulsa Conectar….

MySQL y MariaDB

Además de PostgreSQL, Schevo modela bases de datos MySQL 8.0 o superior y MariaDB 10.6 o superior. Cada modelo tiene un motor, que se ve en la barra de estado (al pulsarlo se abren las propiedades del proyecto):

• Archivo > Nuevo modelo… pregunta el motor del modelo; aparece elegido el último que usaste.
• Archivo > Importar SQL deduce el motor del propio script (comillas invertidas, ENGINE=, AUTO_INCREMENT, DELIMITER…). Si no está claro, pregunta. Se pueden importar scripts escritos a mano, volcados sin datos (mysqldump --no-data o mariadb-dump --no-data, con sus comentarios /*!…*/, SET, USE y vistas provisionales) y exportaciones que crean las claves con ALTER TABLE después de las tablas. Los datos (INSERT…) se ignoran con un solo aviso.
• En Proyecto > Propiedades del proyecto… el motor se puede cambiar libremente mientras el modelo no tenga tablas; con tablas, solo entre MySQL y MariaDB. El esquema por defecto se llama aquí Base de datos: vacío significa «la base de datos actual», y así las tablas se guardan sin esquema (tables/cliente.json) y el SQL generado vale para cualquier base de datos.

El modelo guarda lo propio de MySQL: UNSIGNED y ZEROFILL dentro del tipo (BIGINT UNSIGNED), ENUM/SET con sus valores, juego de caracteres y colación de tablas y columnas, ON UPDATE CURRENT_TIMESTAMP, columnas calculadas (STORED o VIRTUAL), comentarios en línea, opciones de tabla (ENGINE, ROW_FORMAT, AUTO_INCREMENT=, particiones) e índices FULLTEXT, SPATIAL, con prefijo (nombre(10)) o con USING. AUTO_INCREMENT es una columna de identidad BY DEFAULT. Los tipos se normalizan al importar (INTEGER → INT, TINYINT(1) → BOOLEAN, sin el ancho obsoleto de los enteros) y la PK siempre toma el nombre de la convención del proyecto, porque MySQL no guarda su nombre. La definición de un índice admite columna(10) DESC.

Editar los atributos de MySQL: en un modelo MySQL o MariaDB, el editor de tablas (doble clic en una tabla o una columna) tiene una pestaña Opciones de tabla con el motor, el formato de fila, el juego de caracteres y la colación por defecto, el valor inicial de AUTO_INCREMENT, otras opciones y el particionado (PARTITION BY …). Debajo de cada columna se editan su juego de caracteres, su colación, ON UPDATE y, en Calculada, la expresión de una columna calculada con VIRTUAL o STORED; en los índices, el tipo FULLTEXT/SPATIAL y el método (USING BTREE o HASH). Los desplegables sugieren valores habituales y admiten cualquier otro. Un campo vacío significa «lo que diga el servidor» y no se guarda; InnoDB, el motor predeterminado, tampoco. Los valores se escriben como al importar (juego y colación en minúsculas, now() como CURRENT_TIMESTAMP). El nombre de la PK no se edita, porque MySQL no lo guarda. En un modelo PostgreSQL el editor no muestra nada de esto.

El SQL generado tiene un formato fijo, como el de SHOW CREATE TABLE: claves y CHECK dentro de cada tabla, opciones en la línea de cierre y las FK al final. Las rutinas y triggers (sentencias con ; dentro) se escriben entre DELIMITER $$ y DELIMITER ;, también en extra.sql y en el editor de sentencias adicionales: el script está pensado para el cliente de línea de órdenes (mysql base < script.sql), porque DELIMITER no es una sentencia del servidor.

La validación añade las reglas de MySQL/MariaDB: lo que el servidor rechaza (una sola columna AUTO_INCREMENT y en una clave, FK entre enteros de distinto tamaño o signo, textos de distinta colación en una FK, SET DEFAULT, TEXT o JSON en una clave sin prefijo…) es un error, y lo que puede dar problemas (tablas que solo difieren en mayúsculas, colaciones de la otra variante, DESC en MariaDB anterior a 10.8…) es un aviso.

Importar desde una base de datos MySQL o MariaDB: en Archivo > Importar desde base de datos… elige el motor (el puerto pasa a 3306 y se marca Usar SSL); la base de datos es opcional y la lista se llama Bases de datos. El modelo es el mismo que daría su script: las tablas de la base de datos de la conexión van sin esquema, InnoDB y la colación de la base no se guardan, el contador AUTO_INCREMENT no se lee y las vistas, rutinas, triggers y eventos se conservan sin DEFINER. Si MySQL 8 rechaza la contraseña sin SSL, activa SSL: Schevo no descarga la clave pública del servidor. El driver es un fichero aparte, lib/mariadb-java-client.jar (LGPL), que conecta a los dos motores; si falta, Schevo lo dice. Como en PostgreSQL, el servidor reescribe las expresiones (comillas invertidas, paréntesis, curdate()…): al comparar y migrar se comparan en forma canónica.

Script de migración: MySQL y MariaDB no tienen DDL transaccional, así que el script no lleva BEGIN/COMMIT (la cabecera lo recuerda: haz una copia de seguridad y pruébalo antes en otra base). Los cambios de columna van con MODIFY COLUMN y la definición completa; las FK se quitan antes de cambiar sus columnas o el índice que las respalda y se vuelven a crear al final; la PK cambia en una sola sentencia. Los renombrados usan RENAME COLUMN y RENAME TABLE; las FK cuyo nombre cambia se quitan y se vuelven a crear (MySQL no tiene RENAME CONSTRAINT). Se puede migrar entre MySQL y MariaDB, pero no desde o hacia PostgreSQL; comparar sí se puede entre motores. Al comparar un modelo MySQL con el Ejemplo incluido se usa la versión anterior de la tienda MySQL.

Los ejemplos de la tienda en MySQL están en la carpeta examples/mysql del código fuente. MySQL y MariaDB son marcas registradas de sus respectivos titulares.

SQL Server

Schevo modela también bases de datos SQL Server 2017 o superior y Azure SQL Database. Como en PostgreSQL, las tablas llevan siempre esquema (dbo por defecto, tables/dbo.cliente.json). Se elige como los otros motores al crear el modelo o en Proyecto > Propiedades del proyecto…, y Archivo > Importar SQL lo reconoce solo (líneas GO, corchetes, IDENTITY(1, 1), NVARCHAR…). En la línea de comandos, import --dialect sqlserver (o mssql).

• Se importan scripts escritos a mano (sin GO ni ;: cada sentencia acaba donde empieza la siguiente, con IF OBJECT_ID(…) IS NOT NULL DROP TABLE, comillas dobles o corchetes) y los que generan las herramientas de administración del motor (WITH CHECK ADD CONSTRAINT, ADD CONSTRAINT … DEFAULT ((0)) FOR, opciones de índice por defecto, ON [PRIMARY]), estos sin ningún aviso. Los datos se ignoran con un solo aviso; las vistas, procedimientos, funciones y triggers se conservan tal cual.
• Lo propio de SQL Server: IDENTITY(inicio, incremento) (una identidad ALWAYS; la edición rápida identity la crea así), (MAX) dentro del tipo (NVARCHAR(MAX); en la edición rápida notas nvarchar(max) y en el editor la longitud MAX), columnas calculadas AS (expresión) [PERSISTED], que no tienen tipo propio y el diagrama muestra como = expresión, COLLATE por columna, ROWVERSION (TIMESTAMP es su sinónimo antiguo, no una fecha), índices agrupados y no agrupados (PK NONCLUSTERED, CREATE CLUSTERED INDEX), INCLUDE e índices filtrados (WHERE … IS NOT NULL). Los comentarios son las propiedades extendidas MS_Description. El editor de tablas conserva todo esto al aceptar.
• Cada restricción tiene nombre, también los DEFAULT. Si el script no lo pone, Schevo usa uno fijo (<tabla>_pk, la convención de FK, <tabla>_<columna>_uk, <tabla>_<columna>_ck, <tabla>_<columna>_df) en lugar del que inventaría el motor al azar, y el SQL generado lo escribe siempre. Los nombres inventados por el motor (PK__cliente__3B75D760) se respetan y dan un aviso que sugiere renombrarlos.

El SQL generado empieza con SET ANSI_NULLS ON y SET QUOTED_IDENTIFIER ON, escribe cada tabla con sus índices y comentarios en un lote terminado en GO, las FK al final, NULL o NOT NULL en cada columna y los nombres cualificados con el esquema (corchetes solo cuando hacen falta). GO no es T-SQL sino una orden del cliente: el script es para el cliente de línea de órdenes del motor (con -b, que para en el primer error) o el editor de consultas de cualquier herramienta. extra.sql y el editor de sentencias adicionales también ponen un GO tras cada sentencia.

La validación añade las reglas de SQL Server: un solo índice agrupado por tabla, tipos que no se pueden indexar, FK con columnas exactamente iguales (tipo, longitud y colación), y los caminos de cascada: el motor rechaza una FK que deja dos caminos de ON DELETE CASCADE/SET NULL hasta una tabla o un ciclo, así que es un error (pon NO ACTION en alguna). Un UNIQUE sobre una columna que admite NULL es un aviso, porque SQL Server solo admite un NULL: usa un índice único filtrado.

Editor de tablas: en un modelo SQL Server muestra además la casilla NONCLUSTERED de la PK; por columna, la colación, el nombre del DEFAULT (vacío = el implícito <tabla>_<columna>_df) y la columna calculada (expresión y PERSISTED; no lleva tipo); por índice, CLUSTERED, INCLUDE y el filtro WHERE; y la pestaña Opciones de tabla con el almacenamiento (ON grupo) y WITH (…).

Script de migración: el DDL de SQL Server es transaccional y el script va entero en una transacción con SET XACT_ABORT ON; cada sentencia va en su lote, precedido de IF @@TRANCOUNT = 0 SET NOEXEC ON, así que si algo falla se deshace todo y el resto (también el COMMIT) ya no se ejecuta. Antes de un ALTER COLUMN se quitan, y después se vuelven a crear, los índices, claves, CHECK, DEFAULT, FK y columnas calculadas que usan la columna (en tablas grandes puede tardar; ampliar un VARCHAR/NVARCHAR que no está en la PK no toca los índices). Añadir o quitar IDENTITY o convertir una columna en calculada no tiene ALTER: el script lo indica con un comentario «NO MIGRADO» y hay que reconstruir la tabla a mano. Los renombrados aceptados usan sp_rename (también para la PK, las FK y los DEFAULT cuyo nombre cambia con la tabla o la columna). Las columnas nuevas quedan al final de la tabla. Las restricciones con nombre inventado por el motor se emparejan por su contenido al comparar y al migrar.

Base de datos viva: Archivo > Importar desde base de datos… con el motor SQL Server (puerto 1433) lee el catálogo (sys.*) con un usuario y contraseña de SQL Server (no se usa la autenticación de Windows). El servidor puede escribirse servidor\instancia (entonces no se usa el puerto). La casilla Cifrar la conexión (marcada por defecto) cifra y confía en el certificado del servidor, como en los servidores de desarrollo; sin ella, la conexión no se cifra. El usuario necesita el permiso VIEW DEFINITION: sin él, SQL Server oculta parte del esquema sin dar error (Schevo avisa). Las tablas temporales con versión, en memoria o de grafo no se leen. En la línea de comandos, la URL lleva ; y hay que ponerla entre comillas: schevo-cli import --db "jdbc:sqlserver://servidor:1433;databaseName=tienda;encrypt=true;trustServerCertificate=true" modelo --user u, con la contraseña en SQLCMDPASSWORD. Comparar y migrar admiten la base de datos y el Ejemplo incluido de SQL Server.

Los ejemplos de la tienda en SQL Server están en la carpeta examples/sqlserver del código fuente. SQL Server es una marca registrada de su titular.

La ventana

• Lista de tablas (izquierda): filtra escribiendo; un clic lleva a la tabla y el doble clic la edita.
• Diagrama (centro): tablas con su PK arriba, las relaciones como líneas (continua si la FK forma parte de la PK de la hija, discontinua si no) y la «pata de gallo» en el lado de la hija.
• Panel de validación (abajo): errores y avisos del modelo, actualizados mientras editas. Un clic lleva a la tabla y el doble clic la abre. Se puede minimizar, maximizar o cerrar (Ver > Panel de validación, Ctrl+Mayús+V).
• Barra de estado: el resultado de la última acción, los recuentos de validación, el motor del modelo y, durante la prueba, los días que quedan.

Buscar (Ctrl+F) encuentra tablas, columnas, relaciones, índices y comentarios en todo el modelo. Todos los atajos están en Ayuda > Atajos de teclado (Ctrl+F1).

Tablas y columnas

Editar > Nueva tabla… (Ctrl+T) o doble clic en una tabla abre el editor: esquema, nombre, color, comentario, columnas (tipo, longitud, escala, NOT NULL, valor por defecto, comentario y si es PK), índices y restricciones UNIQUE y CHECK. Identidad hace que la base de datos dé el valor de la columna: ALWAYS (siempre) o BY DEFAULT (solo si el INSERT no lo da); se genera como GENERATED … AS IDENTITY, la columna pasa a NOT NULL y tiene que ser de tipo entero y sin valor por defecto. Al importar SQL o una base de datos se conservan sus opciones (START WITH, INCREMENT BY…). Junto al color aparecen los colores ya usados en otras tablas y zonas, para repetirlos con un clic (también en Editar > Cambiar color…, Ctrl+K).

En el diagrama, el nombre de cada columna va en seminegrita y su tipo en gris. Un clic en una columna la marca; si la columna forma parte de relaciones (es una FK, o la referencian otras tablas), esas relaciones destacan sobre el resto de relaciones de la tabla y se marca la columna correspondiente en la otra tabla. El doble clic abre el editor con esa columna seleccionada. Los tipos con una lista de valores muy larga (ENUM y SET de MySQL/MariaDB) se abrevian en el diagrama, p. ej. enum('pendiente','pagado',…); al pasar el ratón por la fila se ve el tipo completo, que también está en el editor.

• Si cambias el tipo de una columna a la que apuntan FK (por ejemplo, la PK), el cambio se copia a las columnas de las tablas hijas, y de ahí a las nietas, para que los dos lados de cada FK tengan el mismo tipo.
• Al renombrar una tabla se actualizan las FK que la referencian y los nombres de PK y FK que seguían la convención.
• Ctrl+C, Ctrl+V y Ctrl+D copian, pegan y duplican tablas (también entre dos ventanas de Schevo). Las copias reciben el sufijo _copia.
• Supr elimina la selección y pregunta si se eliminan también las columnas FK que quedarían sin relación.
• Todo se puede deshacer con Ctrl+Z y rehacer con Ctrl+Y.

Relaciones

Editar > Nueva relación… (Ctrl+R): eliges la tabla padre (la referenciada) y la hija (la que tiene la FK). Las columnas de la hija se proponen a partir de la PK del padre; escribe un nombre nuevo para crearlas. Puedes indicar ON DELETE, ON UPDATE, si es identificadora (las columnas pasan a la PK de la hija) y si admite NULL.

• Al seleccionar una relación se resaltan sus columnas en las dos tablas y aparecen asas: los extremos se pueden llevar a cualquier lado de la tabla y el cuadrado central desplaza el tramo intermedio. Clic derecho > Restablecer trazado automático deshace el trazado manual.
• Clic derecho en una tabla o en una relación permite ir a la tabla padre o a la hija.

Edición rápida

Con el ratón sobre el diagrama:

Diagrama, zonas y notas

• Arrastrar en un espacio vacío desplaza el diagrama; Mayús + arrastrar selecciona varias tablas; Ctrl + rueda hace zoom sobre el cursor (del 10 % al 400 %); Ctrl+9 lo ajusta a la ventana.
• Al seleccionar una tabla se resaltan sus relaciones y sus vecinas y se atenúa el resto (Ver > Resaltar relaciones…).
• Minimapa (Ctrl+M) para moverte por diagramas grandes y modo compacto (Ctrl+Mayús+K), que muestra solo las columnas PK y FK.
• Zonas: rectángulos con título y color para agrupar tablas (Diagrama > Nueva zona o clic derecho). Arrastrar el título mueve la zona con sus tablas, la esquina la redimensiona y el doble clic en el título la renombra. Su nombre también aparece en el minimapa.
• Notas: texto libre en el diagrama. Doble clic para editar y Ctrl+Intro para terminar.
• Diagrama > Alinear a la izquierda y Alinear arriba alinean las tablas seleccionadas.
• Diagrama > Redistribuir automáticamente… vuelve a colocar todas las tablas por prefijo, con los padres a la izquierda.

Validación y reglas de nombres

El modelo se valida continuamente. Son errores, entre otros: FK que apuntan a tablas o columnas que no existen, columnas de PK que admiten NULL, nombres repetidos, SET NULL sobre columnas NOT NULL o valores por defecto que no encajan con el tipo. Son avisos: tipos distintos en los dos lados de una FK, ciclos de ON DELETE CASCADE, palabras reservadas y el incumplimiento de las reglas de nombres. Puedes guardar con errores, pero Schevo te avisa antes.

Proyecto > Reglas de nombres… define las convenciones para PK, FK, UNIQUE e índices con los marcadores {table}, {parent}, {child}, {column} y {columns} (por defecto {table}_pk y {parent}_{child}_fk), y una expresión regular para columnas que deben tener el mismo tipo en todas las tablas (por defecto .*_id). Deja un campo vacío para no comprobar esa regla.

Trabajar con Git

1. Sube el primer commit (importar y guardar) por separado: el SQL pasa a orden alfabético y el cambio es grande aunque el esquema sea el mismo. Los commits siguientes mostrarán solo cambios reales.
2. Haz commit de la carpeta del modelo y del SQL juntos.
3. Como cada tabla está en su fichero y la salida es siempre la misma, dos personas que cambian tablas distintas no entran en conflicto, y mover una tabla solo cambia sus líneas x/y.
4. Si al hacer merge hay conflictos, resuélvelos en los JSON. Al abrir el modelo, Schevo indica el fichero y la línea de los marcadores <<<<<<< que queden. No resuelvas a mano los conflictos del SQL: guarda el modelo (o ejecuta schevo-cli generate) y se regenera.

Cambios desde fuera (git pull)

Schevo vigila la carpeta del modelo abierto. Si cambia fuera de la aplicación (un git pull, un cambio de rama, otro editor):

• sin cambios sin guardar, el modelo se recarga solo, con el mismo zoom, posición y selección;
• con cambios sin guardar, aparece un aviso encima del diagrama con Recargar, que descarta tus cambios y carga lo del disco;
• si los ficheros tienen conflictos sin resolver, el aviso indica cuántos problemas hay (Ver detalles da el fichero y la línea) y el modelo abierto no cambia; al resolverlos se recarga solo;
• si solo cambia el fichero SQL, el aviso ofrece Ver diferencias.

Archivo > Recargar desde disco (F5) vuelve a leer el modelo en cualquier momento.

SQL generado

Al guardar se regenera el SQL asociado (lo puedes cambiar en Proyecto > Propiedades del proyecto…, junto con el esquema por defecto y el fin de línea). Archivo > Generar SQL… (Ctrl+G) muestra primero una vista previa del script con las diferencias respecto al fichero actual: líneas añadidas en verde y eliminadas en rojo, con un recuento y la opción Solo cambios. Desde ahí, Guardar lo escribe en el fichero asociado sin guardar el modelo (si no tiene, pregunta dónde), Guardar como… lo escribe en otro fichero y Copiar lo lleva al portapapeles. Exportar SQL como… lo escribe directamente en otro fichero.

El formato es fijo: tablas en orden alfabético con su PK, UNIQUE y CHECK, después sus índices, y todas las FK al final como ALTER TABLE. Las sentencias que Schevo no dibuja (secuencias, tipos, dominios, extensiones, vistas, funciones, triggers…) se conservan tal cual y se editan en Proyecto > Sentencias SQL adicionales….

Scripts de migración

Archivo > Script de migración (ALTER)… (Ctrl+Mayús+M) genera las sentencias que llevan una base de datos existente desde una versión anterior del modelo hasta la actual. La versión de partida puede ser una revisión de Git (HEAD, origin/develop, una etiqueta…), lo último guardado, otro modelo o script SQL, o el esquema actual de una base de datos (Base de datos > Conectar…), que da justo lo que falta aplicar en ella.

Renombrados. Comparando dos versiones no se puede saber si una columna se ha renombrado o se ha borrado y creado otra, y borrar y crear pierde sus datos. Por eso Schevo busca posibles renombrados y los lista encima del script: una tabla eliminada y otra añadida con las mismas columnas, o una columna eliminada y otra añadida del mismo tipo. Las coincidencias claras aparecen marcadas; las dudosas, sin marcar. Las marcadas se escriben como RENAME (también las PK y FK que cambian de nombre con la tabla) y se conservan los datos; las no marcadas quedan como borrar y crear y se recuerdan en un comentario al final del script.

Revisa siempre el script antes de ejecutarlo: un renombrado que no marques se pierde (borrar y crear) y los cambios de tipo pueden fallar si los datos existentes no se pueden convertir.

Comparar versiones

Archivo > Comparar con otra versión… (Ctrl+Mayús+C) marca en el diagrama las tablas nuevas (verde), modificadas (ámbar, con las columnas cambiadas resaltadas) y eliminadas (rojo discontinuo). Lista de cambios detalla cada diferencia y lleva a la tabla. Las posiciones y colores no cuentan como cambios, ni los DEFAULT y CHECK escritos de otra forma equivalente (p. ej. x BETWEEN 0 AND 4 y (x >= 0) AND (x <= 4)); tampoco generan sentencias en los scripts de migración. Se puede comparar con una revisión de Git, lo último guardado, otro modelo o SQL, o una base de datos viva (Base de datos > Conectar…), por ejemplo para ver qué le falta a la de producción. Hay un ejemplo incluido para probarlo.

Exportar y diccionario de datos

• Archivo > Exportar imagen PNG / SVG / PDF: el diagrama completo, siempre con el tema claro.
• Archivo > Exportar diccionario de datos (HTML): un único fichero con el diagrama, un índice con buscador y, por cada tabla, sus columnas, claves, índices, restricciones, comentarios y relaciones con enlaces.

Línea de comandos y CI

schevo-cli se instala junto a la aplicación:

validate y check no necesitan licencia, para que puedas usarlos en cualquier máquina de integración continua. Hook de pre-commit para no subir nunca el modelo sin su SQL:

#!/bin/sh
schevo-cli check db-model || { echo "Ejecuta: schevo-cli generate db-model"; exit 1; }

Licencia

Schevo incluye una prueba de 30 días con todas las funciones. Después, sin licencia, funciona en solo lectura: puedes abrir, consultar, buscar, comparar y exportar imágenes de tus modelos, pero no editarlos, guardarlos ni generar SQL, migraciones o el diccionario. Tus ficheros nunca dejan de ser accesibles.

Introduce la clave en Ayuda > Licencia… o con schevo-cli license --activate <clave>. La clave se comprueba sin conexión a Internet. Una licencia perpetua sirve para siempre con las versiones publicadas mientras dura su periodo de actualizaciones; una suscripción funciona hasta su fecha de caducidad.

La fecha de caducidad de una suscripción ya incluye 14 días de gracia después del periodo pagado. Durante esos últimos 14 días puedes seguir trabajando con normalidad, pero la barra de estado muestra cuántos días quedan y, al arrancar (como mucho una vez al día), una ventana te recuerda que renueves antes de que Schevo pase a solo lectura. Desde ella, Introducir nueva clave… abre Ayuda > Licencia… para activar la clave renovada.

Actualizaciones

Ayuda > Buscar actualizaciones… consulta en la web de Schevo cuál es la última versión y te dice si estás al día. Si hay una nueva, muestra su fecha y sus novedades, y Descargar abre la página de descarga en el navegador. Schevo nunca instala nada por su cuenta.

Por defecto Schevo también lo comprueba al arrancar, como mucho una vez al día y en segundo plano. Si hay versión nueva, aparece un aviso encima del diagrama; si la comprobación falla (por ejemplo, sin Internet), no se muestra nada. Para desactivarlo, desmarca Ayuda > Buscar actualizaciones automáticamente.

Si no quieres instalar una versión concreta, pulsa Omitir esta versión en el aviso: no se volverá a avisar de ella al arrancar, pero sí de la siguiente que salga. Ayuda > Buscar actualizaciones… la sigue mostrando (indica que la omitiste), por si cambias de opinión y quieres descargarla.

La comprobación solo descarga un pequeño fichero público de la web: no envía tu versión ni ningún dato tuyo ni de tus modelos. La comparación de versiones se hace en tu ordenador.

Idioma, tema y preferencias

• Ver > Idioma: español, inglés, alemán o francés (se aplica al reiniciar). Por defecto se usa el idioma del sistema.
• Ver > Modo oscuro (Ctrl+Mayús+D).
• Schevo recuerda el último modelo, la última carpeta, el tema, el modo compacto, el minimapa y el tamaño del panel de validación.

Recuperación y problemas

• Mientras hay cambios sin guardar se hace una copia de recuperación cada 2 minutos. Si Schevo se cierra de golpe, al volver a abrirlo te ofrece recuperarla.
• Si aparece un error inesperado, el botón Copiar informe copia los detalles técnicos para enviarlos a soporte.
• El registro de la aplicación está en %LOCALAPPDATA%\Schevo\logs en Windows y en ~/.schevo/logs en Linux (Ayuda > Acerca de Schevo > Abrir carpeta de registros).