Idée à creuser le jour où on rencontrera une page avec un traitement Oracle long

Ex : on recherche des tiers

lorsque le serveur reçoit les critères de recherche (tableau $_REQUEST), on créé un md5
du print_r du $_REQUEST
il vérifie si ce md5 est déjà disponible dans une table "requetes_md5", la réponse sera
non
le script exécute les requêtes demandées, supposons qu'il ramène 5 tiers
il stocke les clés primaires de ces 5 tiers, ainsi que les clés primaires de toutes
les autres informations demandées (numéro de téléphone, adresse email, etc...)
dans une table requetes_md5_pk
au fur et à mesure de l'exécution du script, le résultat ne sera pas envoyé à l'écran, mais
stocké dans une variable $html
à la fin du script :
- on stocke dans la table requetes_md5 le md5 des critères, la variable $html, les
dates de modifications des différents scripts appelés, ainsi que la date courante
- on fait un print $html pour envoyer la page au navigateur

Admettons qu'un peu après, on soumets EXACTEMENT la même requête

lorsque le serveur reçoit les critères de recherche (tableau $_REQUEST), on créé un md5
du print_r du $_REQUEST
il vérifie si ce md5 est déjà disponible dans une table "requetes_md5", la réponse sera
cette fois OUI, dans la mesure où les critères sont EXACTEMENT les mêmes
il vérifie ensuite si la date de génération de ce fichier html, qui est donc stocké dans
une base, est plus récente que la date de dernière modification de chacune des enti
tés
stockées dans la base requetes_md5_pk.
il vérifie qu'aucun des scripts appelés n'a été modifié depuis cette date.
Si toutes ces conditions sont réunies, il n'y a à priori pas lieu de refaire la générati
on dynamique de la page, on peut envoyer directement le contenu html

en théorie, ça marche
à voir en pratique, et mesurer le gain de temps

NB
pour LES dates de modifications des différents scripts appelés, on peut les remplace
r par LA date de modification la plus récente de ces scripts
autre approche : faire des triggers sur les différentes tables, qui suppriment les
md5 en cas de changement
ex: soit une page X entièrement statique, la seule chose susceptible de changer, c
'est le menu
on fait un trigger qui supprime le md5 lié à la page X lorsqu'on fait un changement
dans la table menu concernant la page X
un truc comme ça...
à creuser, commencer à le tester sur des pages très simples, puis évoluer sur des pages
de plus en plus compliquées
bien sur, il faut bien tout vérifier...il pourrait y avoir des parties dynamiques
dans la page, par exemple si on choisit d'afficher la date du jour
faire un sleep dans la partie traitement oracle, pour simuler un traitement long
, et voir la différence