Oracle 23c ou 23p comme PostgreSQL ?

Une pluie de nouveautés !

      Balayons rapidement les nouveautés d'Oracle 23c (la Long Term Release qui succède à la 19c). Elles ont été recensées par Tim Hall, d'Oracle-Base (articles de Tim Hall sur Oracle 23c) :

• Rôle prédéfini permettant de "créer" dans une base (DB_DEVELOPER_ROLE)
• Privilèges objet octroyés au niveau des schémas (GRANT .. ANY .. ON SCHEMA)
• (Vrai...) support des booléens (le type BOOLEAN existait déjà en PL/SQL mais pas en SQL)
• Syntaxe directe pour les jointures lors d'un update (UPDATE t1 FROM t2 etc.)
• Utilisation des positions ou des alias de la clause de projection dans la clause de regroupement (GROUP BY)
• Simple notice en DDL au lieu d'une erreur quand un objet existe, n'existe pas (IF EXISTS / IF NOT EXISTS)
• Support quasi complet du standard SQL autour de JSON (le type JSON avait été introduit en 21c)
• Restriction ?!? sur le parallélisme levée
• Pas besoin de DUAL dans certains cas (SELECT sans FROM)
• Domaines (CREATE DOMAIN)
• Constructeur de table (VALUES)

Oracle frappe fort et prend de l'avance sur PostgreSQL ?

      Pas vraiment, non. C'est même tout le contraire. D'abord, certaines de ces nouveautés ne sont pas entièrement abouties au niveau de l'implémentation dixit Tim Hall, spécialement les domaines. Surtout, TOUTES ces nouveautés d'Oracle 23c sont déjà présentes dans PostgreSQL, parfois depuis dix et même vingt ans. Les rares "nouveautés" n'en sont pas, elles sont introduites pour compenser tant bien mal de très mauvais choix conceptuels historiques qui compliquent la vie des développeurs.

      Le rôle prédéfini DB_DEVELOPER_ROLE a par exemple surpris Tim Hall mais c'est sans doute parce qu'il ne connaît qu'Oracle. Pour un DBA Oracle, l'introduction de ce rôle est étonnante car c'est exactement le contraire de ce qu'Oracle recommandait auparavant. La tendance depuis la 10g était plutôt de supprimer ou limiter les rôles prédéfinis. Pour un DBA PostgreSQL, cette nouveauté est bien plus compréhensible. L'introduction de ce rôle contrebalance en effet l'existence de privilèges "système" avec Oracle. Avec ce SGBD, il faut en effet recevoir le droit de créer des tables ou des procédures en général (?!?) au lieu d'avoir le droit de créer dans quelque chose ou de faire usage de quelque chose
      En dehors des quelques attributs comme "login", tout est privilège objet pour PostgreSQL, ce qui est bien plus logique et permet de gérer en amont, facilement et dynamiquement la sécurité. Oracle s'est enfin rendu compte de l'inutilité de son ensemble de privilèges système, un mécanisme complexe qui n'apporte rien au niveau de la sécurité des données.
      Les concepteurs de la 23c tentent enfin de rectifier le tir sans pouvoir aller jusqu'au bout de la démarche afin de ne pas remettre en cause la compatibilité ascendante. Octroyer le rôle DB_DEVELOPER_ROLE est en gros équivalent à un "grant create on database X to Y;" avec PostgreSQL. "En gros" car les DBA Oracle savent bien que recevoir un privilège via un rôle n'est PAS l'équivalent de recevoir un privilège directement, notamment en PL/SQL. De croustillants dialogues de sourds entre DBA Oracle et développeurs modernes sont en perspective ("Tu m'as dit que tu m'avais donné tous les droits pour créer ce que je voulais mais ça marche pas !")

      Certaines autres nouveautés comme la syntaxe directe de jointure pour les update sont des extensions propriétaires de PostgreSQL, hors standard. Il y a certes parfois une petite chose en plus (e.g create user if not exists pas disponible avec PostgreSQL...) mais le coeur d'Oracle reste fondamentalement obsolète sur de nombreux aspects qu'ils auront bien du mal à combler :

• Pas de DDL / DCL transactionnel
• Pas de support des niveaux d'isolation hors READ COMMITTED avec un SERIALIZABLE incomplet et buggé
• Pas de "vrais" schémas. Oracle entretient la confusion entre utilisateur (USER) et schéma (SCHEMA) dans sa documentation. Un utilisateur, un schéma, c'est historiquement la même chose pour Oracle. Malgré les nouveautés 23c, la puissance et la souplesse des schémas reste donc largement inaccessible avec ce SGBD. PostgreSQL gère pleinement le multi-schémas : un utilisateur peut posséder plusieurs schémas. Avec Oracle, c'est impossible. Vous pouvez en 23c octroyer des droits "ANY" limités aux objets d'un utilisateur mais ce n'est toujours pas une vraie implémentation de la notion de schéma et cela pose problème. Tim Hall le note bien, l'implémentation de GRANT ... ANY ... ON SCHEMA est potentiellement une faille de sécurité. Il a raison. Avec PostgreSQL, un utilisateur peut créer plusieurs schémas avec des privilèges dynamiques différents. Il suffit alors pour le développeur de placer ses objets dans le "bon" schéma, en fonction du niveau de confidentialité souhaité, et c'est tout. Avec Oracle, vous devez faire le choix entre simplicité et sécurité. Vous ne pouvez toujours pas non plus avec Oracle supprimer globalement un schéma et ses objets sans supprimer un utilisateur et ses privilèges. Un utilisateur ne peut pas se supprimer lui-même donc le contournement pour supprimer tous les objets de "son" schéma reste de faire du SQL dynamique. Si la suppression du schéma est effectuée sans SQL dynamique par un DBA, elle impose de recréer l'utilisateur et de lui réattribuer ses privilège. Plus étonnant encore, vous ne pouvez toujours pas renommer un schéma (en fait un utilisateur), même en étant DBA, sans faire un export/import (pratique si le schéma contient 10To de données...). Edition-Based Redefinition demeure par ailleurs la fonctionnalité, largement méconnue, qui compense (mal) l'absence de multi-schémas.

• Pas d'indexation partielle hors bidouille
• Pas d'indexation couvrante
• Pas d'indexation BRIN hors Exadata
• Pas d'indexation BLOOM, HASH, GIN, GIST...juste des B-Tree et des Bitmap peu utiles en général et carrément inutilisables en OLTP.

Conclusion

      La 23c pourrait (presque) s'appeler la 23p avec p comme PostgreSQL tant l'effort porte sur le retard accumulé par Oracle depuis des années autour de fonctionnalités utiles et méme essentielles pour les développeurs, notamment le support complet de JSON.
      C'est sans doute trop peu et trop tard. Les mises à jour majeures ne se font pas en claquant des doigts et les cycles sont longs. Un éditeur dont le produit est compatible avec Oracle devra très longtemps composer avec l'absence de ces fonctionnalités en 19c. Il sera sans doute d'ailleurs sur nombre d'aspects plus difficile d'être compatible Oracle 19c et Oracle 23c que PostgreSQL 10 et Oracle 23c !
      Quitte à changer pour une plateforme de développement au goût du jour, autant préférer l'original à la copie et adopter un SGBD nativement plus moderne et extensible. Un très vieux SGBD, même relooké, ne sera jamais PostgreSQL.
      Les carences critiques d'Oracle autour des schémas et au niveau ACID (Atomicity Consistency Isolation Durability) avec un seul niveau d'isolation couvert et encore, uniquement pour le DML (insert/update/delete/merge) perdurent et perdureront. Nul doute que les concepteurs de ce SGBD changeraient cela s'ils le pouvaient mais c'est bien plus difficile que d'ajouter une clause "if not exists" à la commande "create table".

Mise à jour : 12/04/2023