Skip to content

Bases de données ​

Faites un clic droit sur une base de données dans la barre latérale pour voir ses propriétés, changer son jeu de caractères ou la renommer.

Propriétés de la base de données ​

Propriétés de la base de données affiche le nom de la base, son jeu de caractères par défaut et sa collation. Chaque valeur a un bouton Copier, et Tout copier place les trois dans le presse-papiers en une fois :

text
Name: shop
Character set: utf8mb4
Collation: utf8mb4_unicode_ci

La signification des deux valeurs dépend du moteur :

MoteurJeu de caractèresCollation
MySQL / MariaDBJeu de caractères par défaut de la baseCollation par défaut
PostgreSQLEncodage (par ex. UTF8)datcollate, la locale selon laquelle les chaînes sont triées
SQL ServerPage de code de la collation (par ex. CP1250, UTF-8 (CP65001))Collation de la base
SQLitePRAGMA encodingBINARY

Changer le jeu de caractères et la collation ​

Sur MySQL et MariaDB, la fenêtre des propriétés propose Changer le jeu de caractères…. Choisissez le jeu de caractères — la collation passe à la valeur par défaut de ce jeu, et vous pouvez en choisir une autre.

Avec Appliquer aussi à toutes les tables et à tous les champs de la base coché (par défaut), la modification ne s’arrête pas à la valeur par défaut de la base. La fenêtre compte les tables et les champs texte et indique combien de tables doivent réellement être converties ; les tables déjà dans la collation choisie sont ignorées.

Appliquer demande confirmation, puis :

  1. change la valeur par défaut de la base (ALTER DATABASE … CHARACTER SET … COLLATE …), afin que les tables créées par la suite reçoivent le nouveau jeu ;
  2. convertit les tables une par une avec ALTER TABLE … CONVERT TO CHARACTER SET …, ce qui change la valeur par défaut de la table et chaque colonne CHAR, VARCHAR, TEXT, ENUM et SET.

Une barre de progression indique la table en cours de conversion. Arrêter termine l’opération après la table en cours. Une table en échec n’arrête pas les autres ; chaque erreur est listée à la fin avec le nom de la table.

Les clés étrangères sur des colonnes texte ne gênent pas : chaque conversion s’exécute avec la vérification des clés étrangères désactivée, de sorte qu’une table enfant peut changer avant sa table parente. Les clés restent en place et sont appliquées comme avant.

Chaque table est reconstruite

CONVERT TO réécrit la table et la verrouille pendant toute l’opération, ce qui prend du temps sur une grande table. Passer à un jeu multi-octets comme utf8mb4 peut aussi transformer une colonne TEXT en MEDIUMTEXT pour conserver sa capacité. Faites d’abord une sauvegarde.

Les vues n’ont pas de colonnes propres et ne sont pas converties. Les procédures stockées et les fonctions conservent la collation avec laquelle elles ont été créées ; recréez-les si elles doivent utiliser la nouvelle.

PostgreSQL, SQL Server et SQLite affichent les valeurs en lecture seule : aucun d’eux ne peut modifier cela en toute sécurité pour une base existante.

Renommer une base de données ​

Renommer la base de données… se trouve dans le menu contextuel de la base pour MySQL, MariaDB, PostgreSQL et SQL Server. Une base SQLite est un fichier — renommez-la en modifiant la connexion.

PostgreSQL et SQL Server ​

Les deux renomment avec une seule instruction (ALTER DATABASE … RENAME TO et ALTER DATABASE … MODIFY NAME). Les tables, les autres objets et les permissions restent en place.

Le serveur a pour cela besoin d’un accès exclusif à la base. La fenêtre indique combien d’autres sessions l’utilisent, et Déconnecter les autres sessions les expulse d’abord — leurs transactions ouvertes sont annulées. NabuSQL ferme automatiquement ses propres connexions à la base.

Sur SQL Server, les fichiers physiques (.mdf, .ldf) conservent leurs noms.

MySQL et MariaDB ​

MySQL et MariaDB n’ont pas d’instruction pour cela, NabuSQL reconstruit donc la base sous le nouveau nom. La fenêtre explique les étapes, liste le contenu de la base, et le bouton Renommer reste désactivé tant que vous n’avez pas coché Je comprends le risque et j’ai une sauvegarde de la base de données.

Ce qui se passe :

  1. Chaque définition qui ne peut pas être déplacée — déclencheurs, vues, procédures, fonctions, événements, privilèges — est d’abord lue et enregistrée dans nabusql_rename_<database>_<time>.sql dans votre dossier Téléchargements. Si l’une d’elles ne peut pas être lue, rien n’est modifié.
  2. La nouvelle base est créée avec le même jeu de caractères et la même collation.
  3. Les déclencheurs sont supprimés (MySQL ne déplace pas une table qui en a un), puis toutes les tables sont déplacées par un seul RENAME TABLE. C’est rapide — seules les métadonnées changent, aucune ligne n’est copiée. Les séquences MariaDB et les tables versionnées par le système sont déplacées de la même façon, ces dernières avec leur historique. Les valeurs par défaut de colonnes qui puisent dans une séquence (DEFAULT NEXTVAL(…)) sont ensuite redirigées vers la séquence déplacée : MariaDB les enregistre avec l’ancien nom de base, elles casseraient donc dès que cette base serait supprimée.
  4. Les procédures et fonctions, vues, déclencheurs et événements sont recréés dans la nouvelle base. Les références écrites sous la forme `old`.table sont redirigées vers le nouveau nom. Les déclencheurs conservent leur ordre de déclenchement et le sql_mode avec lequel ils ont été créés.
  5. Les privilèges des utilisateurs sur la base, ses tables et ses routines sont copiés vers le nouveau nom.
  6. Seulement si toutes les étapes ont réussi, les anciens privilèges sont révoqués et l’ancienne base, désormais vide, est supprimée.

Si l’étape 3 échoue, elle est annulée : les déclencheurs sont recréés et la nouvelle base supprimée. Si quelque chose échoue après le déplacement des tables, l’ancienne base est conservée, avec ce qui n’a pas pu être recréé, et le résultat liste chaque étape avec son état.

Pas atomique, et rien n’est modifié en dehors de cette base

Les vues, routines et déclencheurs d’autres bases, ainsi que les applications qui se connectent à l’ancien nom, continuent d’utiliser l’ancien nom. Personne d’autre ne doit travailler sur la base pendant son renommage.

Lorsqu’un compte DEFINER n’existe pas ou que vous n’avez pas le privilège de l’utiliser, l’objet est créé avec vous comme DEFINER, et le résultat le signale.

Ce que NabuSQL met à jour pour vous ​

Après tout renommage, NabuSQL redirige ses propres références vers le nouveau nom : requêtes enregistrées, onglets ouverts, tâches du planificateur, base par défaut de la connexion et dossier des requêtes enregistrées sur le disque.