Plsql

SQL, c’est cool.
Tu peux récupérer des données, faire des requêtes, des jointures, des agrégations… bref, t’extrais de l’info.

Mais dès que tu veux faire du vrai traitement, genre de la logique métier directement dans la base de données… SQL, c’est un peu léger.

Dans les années 80, Oracle a vu le problème et s’est dit :
“OK, SQL c’est bien, mais et si on lui collait un vrai langage de programmation aux fesses ?”

Et PL/SQL est né.

L’idée ? Ajouter des variables, des boucles, des conditions, des procédures stockées, des triggers… bref, tout ce qu’un dev aime pour automatiser et structurer son code directement dans la base.

Pourquoi ?

• 👉 Performance : Plutôt que de faire 36 allers-retours entre l’application et la base, tu fais bosser le SGBD directement. Résultat : c’est plus rapide.
• 👉 Sécurité : Tu peux encapsuler la logique métier dans la base, éviter que n’importe qui balance des requêtes dégueulasses et crame ton intégrité de données.
• 👉 Maintenance : Plutôt que d’avoir du code SQL disséminé dans l’appli, tu centralises dans des procédures stockées, et tout le monde s’aligne dessus.

Problème ?
PL/SQL, c’est Oracle only. Et Oracle, bah… c’est Oracle.

Tu veux en sortir ? Bonne chance.
Tu veux migrer vers PostgreSQL, MySQL ou SQL Server ? Faudra réécrire une bonne partie de la logique.

Aujourd’hui, PL/SQL reste un monstre de puissance pour les entreprises qui tournent sur Oracle, mais avec la montée des bases open-source et du cloud, beaucoup cherchent à s’en débarrasser.

Moralité : Quand tu choisis une techno, pense toujours à comment tu vas en sortir.

👉 T’as déjà dû bosser avec PL/SQL ? Team “puissance et contrôle” ou “fuite à tout prix” ?