Votre schéma de base de données, en code lisible.

Un langage de schéma lisible

Tables, types logiques, clés primaires et étrangères (->), index (partiels et d’expression), contraintes check et enums s’écrivent dans des fichiers .tabliva. Les particularités de chaque dialecte s’ajoutent par annotations (@postgres(type: "jsonb")) ; vues, déclencheurs et fonctions, par des blocs sql bruts. L’éditeur offre la coloration syntaxique, la complétion et la recherche.

Diagramme ER bidirectionnel

Le diagramme se met à jour pendant la saisie ; en cas d’erreur de syntaxe, le dernier état valide reste affiché et l’erreur est indiquée avec sa ligne. Ajouter, renommer ou supprimer des tables, colonnes, relations et index, ou changer un type dans le diagramme ne réécrit que la ligne de code concernée ; les commentaires sont conservés. La disposition est enregistrée dans un fichier à part (diagram.tabliva-layout.json).

Problèmes : 55 règles

Clés, suggestions de clés étrangères manquantes avec niveau de confiance, types (p. ex. float pour des montants), index, données répétées, nommage, structure et compatibilité avec le dialecte. Chaque problème a une explication simple et une correction ; les corrections sûres s’appliquent en une fois. Ignorer un problème ou désactiver une règle est écrit dans le fichier kurallar.tabliva.

Normalisation

Les dépendances fonctionnelles se déclarent dans le code par une ligne depends ou sont suggérées à partir des noms de colonnes. Pour chaque table s’affichent les étapes de la 1NF à la BCNF, des corrections avec aperçu avant / après (déplacer vers une autre table, nouvelle table, table enfant, copie volontaire) et le SQL de migration des données pour le dialecte.

Plan de modifications et fichiers de migration

Le code est comparé à une cible (dossier de migrations, instantané ; sur ordinateur, une base de données en direct). Les renommages sont détectés ; chaque étape porte des étiquettes de risque comme la perte de données, la réécriture de la table ou le verrouillage. Le SQL est généré pour PostgreSQL, MySQL / MariaDB et SQLite ; le fichier de migration est écrit dans le dossier migrations/ sous un nom daté et sa somme de contrôle est ajoutée à tabliva.sum.

Importer un schéma existant

Les exports SQL (pg_dump, mysqldump, SQLite .schema ou CREATE TABLE écrit à la main), le DBML et un autre projet Tabliva sont lus ; on choisit un fichier par table ou un fichier unique. Seul le schéma est repris ; les lignes INSERT et COPY sont ignorées. Sur ordinateur, le schéma peut aussi être lu directement depuis une base de données.

Toutes les fonctionnalités