Discussion :

[shogunFR]

Bonjour,

je suis actuellement sur une analyse d'un problème :

Sur une base 9i, le schema de la base de données a été defini pour permettre la persistance d'objets metiers assez souples :

il existe une table OBM avec tres peu de caractéristiques (juste des clé et quelques grandeurs) , le reste des champs est géré sous forme d'une table associée PRM comportant pour chaque ligne une reference de FK vers OBM , une code de champ et une valeur.
(le code etant contraint par un table catalogue CATPRM des valeurs de parametres acceptables)

pour un usage backoffice tout se passe bien. les temps de reponses sont acceptables pour les traitemements.

On desire maintenant enrichir un frontoffice permettant a des utilisateurs de rechercher avec de nombreux criteres sur les fameux objets.
En presentant le tout dans des tableaux où chaque ligne est un objet
On veut assurer les fonctions de tri et pagination.

les etapes sont donc
extraction des candidats selon les criteres
lecture des objets complets
transformation sous forme tabulaire
tri sur un vaeur d'un champ
pagination

plusieurs scenarios possibles

scenario 1

sur le sgbd :
extraction des candidats selon les criteres
lecture des objets complets

sur le serveur d'appli
transformation sous forme tabulaire
tri sur un champ
pagination
affichage et cout de peinture (css)


scenario 2

sur le sgbd :
extraction des candidats selon les criteres
lecture des objets complets
transformation sous forme tabulaire
tri sur un champ
pagination

sur le serveur d'appli
affichage et cout de peinture


pour des raisons de cout / perennité / maintenante , on veut eviter les devs coté serveur appli

le scenario 1 est donc privilégié

en detail cela donne :

a) extraction des candidats selon les criteres :
les criteres de l'ihm aboutissent donc a des couples code+ de parametre.
la requete d'extraction des canddats ressemble donc a un truc du genre
par exemple avec 2 criteres renseigné :
selec obm.id
from obm, prm p1, prm p2, ...
where
obm.id = p1.id and prm.cpde_prm = 'codeparam' and prm.valeur = 'valeurparam'
and
obm.id = p2.id and prm.cpde_prm = 'codeparam' and prm.valeur = 'valeurparam'
and
....

b) lecture des objets complets
pour recuperer le contenu des objets complets on recupere par jointure tous les elements de la table PRM associés aux id selectionnés ci dessus


c) Transformation des elements sous forme tabulaire :
la ca se corse... le pivot c'est pas une fonction de base d'oracle
mais avec une requete bien sentie on y arrive du genre :
SELECT id,
MAX(DECODE(code_prm,p1,valeur,null)) P1,
MAX(DECODE(code_prm,p2,valeur,null)) P2,
MAX(DECODE(code_prm,p3,valeur,null)) P3,
FROM ( <ma_requete_de_selection>)
GROUP BY id...

nb : cette requete est bien sur autogénérée d'apres le catalogue des parametres

d) on peut ensuite trier ce resultat sur une colonne (P1 par exemple)

e) paginer coté oracle pour ne recuperer que l'information utile .

(la pagination client side est possible si on a une technologie de cache sur la session de l'utilisateur connecté mais vu l'usage, on se rend compte que l'utilisateur deborde rarement de 1ere page, il raffine plutot en modifiant les criteres)

Ceci fait un bon nombre d'operation a faire coté serveur

les volumetries en jeu sont
OBJ : ~ 1 Million d'enregistrement
PRM ~ 100 a 200 parametres instanciés

j'aimerais avoir votre position sur l'utilisation devue materialisée pour precalculer les taches b) et c)
des indexs orientés sur les criteres utilisés dans les requetes permettant de de tuner la partie a) et d) a l'execution

les données de PRM sont mises a jour au fil de la journée par les memes utilisateurs. ils s'attendent donc a trouver une information a jour quand ils font une recherche apres avoir modifié un parametre via leur application
pour cela j'envisage des vues materialisées rafraichies tres souvent voire en temps reel par rapport a la source.

[pifor]

les données de PRM sont mises a jour au fil de la journée par les memes utilisateurs. ils s'attendent donc a trouver une information a jour quand ils font une recherche apres avoir modifié un parametre via leur application
pour cela j'envisage des vues materialisées rafraichies tres souvent voire en temps reel par rapport a la source.

A priori, l'utilisation de vues matérialisées dans un environnement transactionnel est déconseillé si les données utilisées par les vues peuvent être mises à jour: le gain de temps d'exécution des requêtes SELECT risque d'être perdu lors de la mise à jour des vues matérialisées nécessaires pour un rafraîchissement en "temps réel".

Si vous avez le temps, il faudrait confirmer ceci par un prototype qui devrait être le plus représentatif possible d'un cas d'utilisation de votre système.