Réordonner les colonnes d’une table Oracle : l’astuce des colonnes invisibles

Voici un problème que tout utilisateur d’Oracle rencontre un jour : vous ajoutez une colonne à une table existante, et elle se retrouve fatalement en dernière position. Or vous auriez aimé qu’elle apparaisse ailleurs — par exemple un identifiant que vous voudriez voir en tête. Contrairement à d’autres systèmes, Oracle ne propose aucune commande directe du type « déplacer cette colonne ». Alors comment réordonner les colonnes d’une table Oracle ?

La réponse évidente serait de reconstruire la table (la recréer dans le bon ordre, copier les données, basculer). Mais c’est lourd, et risqué si la table contient déjà des données. Il existe une astuce bien plus légère, exploitant une fonctionnalité méconnue d’Oracle : les colonnes invisibles.

Le principe : les colonnes invisibles

Depuis Oracle 12c, une colonne peut être marquée invisible. Une colonne invisible existe toujours, contient toujours ses données, reste indexable et interrogeable — mais elle n’apparaît plus dans un SELECT *, ni dans un DESCRIBE, ni dans un INSERT sans liste de colonnes. Elle est simplement masquée de l’ordre d’affichage par défaut.

C’est le comportement suivant qui rend l’astuce possible : quand on rend une colonne invisible, elle perd sa position dans l’ordre des colonnes ; et quand on la rend à nouveau visible, elle est replacée en dernière position.

Ce détail est la clé de toute la technique. En jouant sur l’ordre dans lequel on rend les colonnes visibles, on peut reconstruire l’ordre logique complet de la table — sans jamais la réécrire.

La technique, étape par étape

Prenons une table clients avec les colonnes dans cet ordre : nom, email, id. On souhaite que id passe en première position.

L’idée : rendre invisibles les colonnes qui doivent passer après id, puis les rendre visibles une par une dans l’ordre voulu. Comme chaque colonne rendue visible se place en dernier, l’ordre final correspond à l’ordre de « revisibilisation ».

-- État de départ : nom, email, id
-- Objectif : id, nom, email

-- 1. Rendre invisibles les colonnes à replacer après id
ALTER TABLE clients MODIFY (nom INVISIBLE, email INVISIBLE);
-- Ordre logique actuel : id (les deux autres sont masquées)

-- 2. Les rendre visibles dans l'ordre souhaité
ALTER TABLE clients MODIFY (nom VISIBLE);
-- nom repasse en dernier -> ordre : id, nom
ALTER TABLE clients MODIFY (email VISIBLE);
-- email repasse en dernier -> ordre : id, nom, email

Résultat : les colonnes sont désormais dans l’ordre id, nom, email, sans qu’on ait touché aux données ni recréé la table. Pour réordonner toutes les colonnes d’une table, on applique la même logique : on rend tout invisible (sauf au moins une colonne, car Oracle exige qu’il reste au moins une colonne visible), puis on rend visible dans l’ordre cible.

Pourquoi c’est intéressant

Comparée à la reconstruction complète de la table, cette méthode présente de vrais atouts :

• Aucune réécriture de la table. C’est une opération sur les métadonnées (le dictionnaire de données), pas sur les données elles-mêmes. Elle est donc quasi instantanée, même sur une grosse table.
• Aucune copie de données ni table intermédiaire, donc pas besoin d’espace disque supplémentaire.
• Les index, contraintes et clés étrangères restent intacts, puisqu’on ne touche pas à la structure physique.

Là où une reconstruction imposerait de copier toutes les lignes et de recréer tous les objets associés, l’astuce des colonnes invisibles atteint le même but — réordonner — en quelques instructions légères.

Les précautions à connaître

Cette technique est élégante, mais elle n’est pas sans pièges. Trois points de vigilance méritent l’attention.

1. C’est purement cosmétique. L’ordre des colonnes ne change que sur le plan de l’affichage logique. Le stockage physique sur disque, lui, n’est pas modifié. Et surtout, l’ordre des colonnes n’a aucun impact sur les performances ou le fonctionnement des requêtes en SQL. Cette manipulation ne se justifie donc que pour le confort de lecture ou pour aligner l’ordre sur une référence — jamais pour un gain technique.

2. Attention aux applications pendant l’opération. C’est le risque principal. Pendant que des colonnes sont invisibles, une requête SELECT * ou un INSERT sans liste de colonnes explicite ne verra pas les colonnes masquées. Si l’application tourne pendant que vous exécutez le script, elle peut se comporter de façon erratique, voire échouer. Cette opération doit donc se faire pendant une fenêtre de maintenance, application à l’arrêt ou en accès contrôlé.

3. Réservé à Oracle 12c et suivants. Les colonnes invisibles n’existent que depuis la version 12c. Sur une version antérieure, cette astuce n’est pas disponible et il faut revenir à la reconstruction classique.

Un mot sur le COMMIT

Un détail technique utile, souvent mal compris : en Oracle, chaque instruction de définition de données (DDL), comme ALTER TABLE, déclenche automatiquement un COMMIT implicite, avant et après son exécution. Il est donc inutile d’ajouter des COMMIT explicites entre les ALTER TABLE — ils ne font pas de mal, mais n’apportent rien et alourdissent le script. Une suite d’ALTER TABLE se valide toute seule, instruction par instruction.

Quand l’utiliser (et quand s’abstenir)

Cette astuce est le bon outil quand vous voulez réaligner l’ordre logique des colonnes d’une table existante — par exemple après avoir ajouté des colonnes au fil du temps, ou pour faire correspondre l’ordre d’une table à un modèle de référence. Dans ce cas précis, elle est bien plus légère qu’une reconstruction.

En revanche, si votre besoin va au-delà du simple réordonnancement — changer des types, ajouter des contraintes complexes, restructurer en profondeur — vous sortez du périmètre de cette astuce et revenez aux méthodes générales de modification de structure. C’est justement le sujet de notre guide sur les différentes méthodes pour modifier la structure d’une table non vide, où le réordonnancement des colonnes n’est qu’un cas particulier parmi d’autres.

Retenez surtout le principe : une colonne rendue visible passe en dernier. Tout le reste découle de cette règle simple, qui transforme une fonctionnalité de masquage en outil de réorganisation.