piapia123
es

Diseño de base de datos: diagrama ER, cambio de dialecto y comprobación

Web

Todo se ejecuta en tu navegador: no se sube nada

Relaciones entre tablas (PK / FK marcadas)

Pega tu DDL a la izquierda y a la derecha obtienes tres cosas: 1. Un diagrama de relaciones — una caja por tabla, con las claves primarias y ajenas marcadas y las ajenas dibujadas como conectores; 2. Las mismas tablas en tu dialecto de destino — MySQL, PostgreSQL o SQLite, con tipos y autoincremento reescritos; 3. Una comprobación estructural — la parte que vale por sí sola. Por qué la comprobación merece la pena por separado: encontrar esto a ojo entre docenas de tablas es imposible, y cada punto es un hecho: · Una clave ajena que apunta a una tabla o columna que no existe (invisible en un diagrama, fatal al ejecutar el DDL); · PostgreSQL no indexa automáticamente las columnas de clave ajena (MySQL sí): las uniones y el borrado de la tabla padre se vuelven más lentos; · Falta de clave primaria, nombres de columna duplicados, autoincremento sobre un tipo no entero; · Una columna con nombre de palabra reservada de SQL y sin comillas (casi todas las bases de datos se niegan a analizarla); · `VARCHAR` sin longitud (MySQL lo rechaza, PostgreSQL lo trata como ilimitado); · Sin cláusula `ON DELETE` (la predeterminada, RESTRICT, bloqueará el borrado de una fila padre). La conversión nunca descarta nada en silencio: el mapa de tipos es una tabla corta y explícita, y todo lo que se convierte mal o pierde significado (el `unsigned` de MySQL, `ON UPDATE CURRENT_TIMESTAMP`, `ENUM`) lleva una nota. No deberías descubrir un constraint que falta meses después de ejecutar la salida. La sintaxis admitida es deliberadamente estrecha: solo `CREATE TABLE` y `ALTER TABLE ... ADD CONSTRAINT ... FOREIGN KEY`. Las vistas, los disparadores y las expresiones de columnas generadas no se analizan: cualquier cosa no reconocida produce un aviso de «esta línea se omitió» en lugar de una conjetura (descartarla en silencio te dejaría un diagrama precioso al que le falta una tabla). Todo se ejecuta en tu navegador; no se sube nada.

Funciones

  • Diagrama de relaciones: nombres de tabla y columna, tipos, marcas PK / FK, conectores de clave ajena
  • DDL para tres dialectos: MySQL, PostgreSQL y SQLite
  • Mapa de tipos: AUTO_INCREMENT → SERIAL, DATETIME → TIMESTAMP, TINYINT(1) → BOOLEAN y más
  • Las sentencias generadas van en orden de dependencia (primero las tablas referenciadas), así que el bloque entero se ejecuta
  • Comprobación estructural: claves ajenas rotas, índices que faltan, claves primarias, columnas duplicadas, palabras reservadas, sintaxis de tipos, ON DELETE
  • Los hallazgos se clasifican en error / aviso / nota, cada uno nombrando el objeto exacto
  • Las notas de conversión listan cada comportamiento perdido en vez de esconderlo
  • Las líneas que no se pudieron analizar se reportan, nunca se descartan en silencio
  • Los identificadores solo se entrecomillan cuando hace falta (palabras reservadas o caracteres especiales)
  • Ctrl / Cmd + Enter para analizar; hay un esquema de ejemplo precargado

Cómo se usa

  1. Pega tu DDL en el cuadro (o usa el ejemplo precargado)
  2. Elige un dialecto de destino: MySQL, PostgreSQL o SQLite
  3. Pulsa Analizar, o Ctrl / Cmd + Enter
  4. El diagrama aparece a la izquierda; las tablas, los hallazgos y el SQL generado a la derecha
  5. Usa el botón de copiar de cada fila para llevarte el DDL generado

Preguntas frecuentes

¿Qué sintaxis SQL se admite?
Solo `CREATE TABLE` (definiciones de columna, claves primarias a nivel de columna y de tabla, unique, índices, claves ajenas, CHECK) y `ALTER TABLE ... ADD CONSTRAINT ... FOREIGN KEY`. Las vistas, los disparadores, los procedimientos almacenados, las columnas generadas y las expresiones `DEFAULT` complejas no se analizan, y producen un aviso de «esta línea se omitió». Mejor no decir nada que inventar.
¿Por qué avisa de una clave ajena sin índice en PostgreSQL?
Porque PostgreSQL no indexa las columnas referenciantes de una clave ajena, mientras que MySQL (InnoDB) sí. Sin índice, las uniones y el borrado de filas padre degeneran en un escaneo. El aviso es específico del dialecto: no aparece al seleccionar MySQL.
¿Es fiable la conversión de tipos? ¿Qué se pierde?
El mapa es una tabla corta y explícita (unas veinte clases comunes) que puedes contrastar con la salida. Las conversiones que pierden significado siempre llevan nota: `unsigned` no tiene equivalente en PostgreSQL (cambia el rango), `ENUM` pasa a TEXT (se pierden los valores permitidos) y `ON UPDATE CURRENT_TIMESTAMP` necesita un disparador en el dialecto de destino. Los tipos fuera de la tabla se conservan tal cual con un aviso, sin inventar.
¿Puedo ejecutar las sentencias generadas?
Sí, y van ordenadas por dependencia (primero las tablas referenciadas), así que ejecutar el bloque entero no fallará por una clave ajena a una tabla que aún no existe. Dos advertencias: SQLite no aplica las claves ajenas salvo que cada conexión ejecute `PRAGMA foreign_keys = ON` (el SQL generado lo dice), y no se genera lógica de migración de datos: mover las filas existentes es cosa tuya.
¿Funciona al revés, desde una base de datos en vivo?
No, aquí no hay servidor que se conecte a tu base de datos. Pero puedes exportar el DDL con `mysqldump --no-data`, `pg_dump --schema-only` o `sqlite3 .schema` y pegarlo: que es como se suele usar esta herramienta.

Herramientas relacionadas