numéro 27 juin 2023 Des technologies du numérique universitaire : place aux makers ! la collection numérique
AY
14 Certains choix technologiques engagent sur le (très) long terme La preuve par Apogée A\\
VOYAGE DANS LE TEMPS
Nous sommes au siècle dernier et même au millénaire précédent .
Un choix technologique dit « Full Oracle » pour ce琀琀e naissante solu琀椀on prénommée Apogée .
Un choix qui signi昀椀e à la fois le stockage des don- nées dans une base de la 昀椀rme à la couleur rouge et les éléments du client (et oui une époque révolue du client/serveur) , la par琀椀e de l’ou琀椀l u琀椀lisée par les usagers , sur ses technologies propriétaires également .
Se pose alors la ques琀椀on de traitements , synchrones et asynchrones , parfois complexes : Comment les coder ? Où les posi琀椀onner ? quelle technologie choisir .
Le choix s’arrête sur des procédures stockées (昀椀che wikipedia ici) , techniquement appelées packages .
« Procédures » car le langage est procédural .
« Stockées » car elles sont portées et intégrées dans la base de données .
Le langage associé , pour Oracle , est le PL/SQL une version propriétaire .
A\\
UN CHOIX ÉVOLUTIF
? Peu d’alterna琀椀ves en ces temps lointains pour cet ensemble de code .
Un posi琀椀onnement coté serveur semble évident , le choix de la tech r nologie des procédures stockées coulait de (code) source .
Exécu琀椀on au cœur de la base de données , puissance du serveur , un code par r tageable par tous les cons琀椀tuants du logiciel : traitements , écrans , édi琀椀ons , autres procédure , ou琀椀ls de la téléma琀椀que (cela con昀椀rme que l’on parle ici d’une technologie antédiluvienne),...
En termes d’urbanisa琀椀on , on peut s’interroger aujourd’hui sur la per琀椀nence de poser des traitements au sein même du moteur de la base de données .
Les architectures ont tellement évolué .
Même si la technologie des procédures stockées est assez générique , on en retrouve chez les grands éditeurs de bases de données , le lan r gage est lui propriétaire et spéci昀椀que .
témoignage auteur David Rongeat , développeur 90’s , Amue Aussi , aux moments où se sont posées plu r sieurs fois les ques琀椀ons de changement ou d’évolu琀椀on du moteur de base de données ou de l’architecture générale , l’existence d’un volume de milliers de pages de code en PL/SQL était un frein à ces évolu琀椀ons .
Il eu fallu alors transformer ce code vers un autre langage de procédure stockées ou le réécrire , l’adapter , le retester… Une époque sans
IA
pour faire ce travail .
A\\
MAIS ALORS
Celles et ceux qui ont codé en PL/SQL recon r naitront l’intérêt de ce langage , dans son contexte , on parlait d’élégance du code ; un code qui survit en approchant la trentaine .
Des architectes peuvent fus琀椀ger , à raison , un choix technique qui a bloqué du code et un moteur de base de données dans une tech r nologie propriétaire ; en sommes des procé r dures stockées indéstockables .
Di昀케cile de trancher après ce voyage dans le temps pour savoir si ce choix technologique était le bon ou un facteur trop limitant à l’évo r lu琀椀on technique .
En tous cas , c’est le choix fait au milieu des années 90 qui demeure .