Discussion :

[6rose]

Bonjour,

Voici mon dilème :
Je suis en train de bosser sur la refonte d'un erp d'une ancienne techno vers une application java utilisant une base Oracle.

L'application va comporter dans les 1000 tables.
Nous souhaitons donc la découper en module pour en faciliter le developpement et la maintenance.
Le but étant que le developpeur d'un module (qui aura forcement besoin d'acceder aux données des autres modules)
ne requete pas sur toutes les tables de l'application.
Cela necessiterait qu'il metrise tout le schéma.
J'avais pour idée que chaque module ait son schema et qu'il mette a dispo aux autres modules des vues pour l'acces aux données de son module.
Cela permetrait de masquer la complexité de chaque modules (genre une vue regroupant 3 tables avec moins de colonnes).
J'ai fait quelques tests de performances pour l'utilisation des vues, mais mes résultat était décevant...
Car la performance est aussi une priorité pour l'application.
Qu'en pensez vous?

[Garuda]

Les vues, ca me parait pas faisable.
Notamment pour la maj.
Par contre tu peux creer tes tables sous différents users.
Et creer des synonymes soit publics (pour tous les users), soit privés (pour un seul user)

[plabrevo]

Bonjour,
J'ai fait quelques tests de performances pour l'utilisation des vues, mais mes résultat était décevant...

La conclusion est un peu rapide, entre la manipulation d'une table et celle d'une vue basee sur cette table, la difference se joue probalement en nanosecondes. Autrement dit, si les performances sont mauvaises au travers de la vue, elles le seront tout autant au travers de la table, ce qui peux signifier des problemes de requetes mal ecrites, un datamodel mediocre, l'absence d'indexes, etc...

[Bruno2r]

Je suis d'accord avec plabrevo la lenteur ne s'explique pas par l'usage des vues qui fonctionnent très bien même en dblink entre bases.
Mais j'adopterais la même solution que Garuda regrouper les tables en autant de users que de modules vu le nombre de tables annoncées environ 1000 et l'emploi de synonymes en public ou privé

[6rose]

Merci pour toutes vos reponses.

Les vues répond bien a mes attentes, car chaque module a le droit de modifier uniquement les données de son module (gestion faite coté java).

Par contre mes pb de performances avec vue, sont des problème de plan de jointure ex :

Module 1

Tables : Gencod, Type_Gencod, ...


Module 2

Tables : Collecte, ....

Le module 1 est responsable des données des gencod (type, libelle, etc, ...). C'est le referentiel. Le module 2 se contente de faire des collectes de gencod.

L'idée c'est que le module 2 à besoin d'afficher les infos des gencod de sa collecte si le gencod est connu dans le module 1.

la requete basique serait :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
select * 
from Collecte c
left outer join Gencod g on (g.gencod = c.gencod)
inner join Type_Gencod  t on (g.type_id = t.type_id)

Ca c'est performant pas de problème mais les modules ne sont pas séparé.
PS : je n'ai bien sur pas utilisé *, c'est juste pour l'exemple.

Maintenant je decide de faire une vue pour donner l'acces aux données du module 1 au module 2

Je construit une vue qui contiendra les infos du gencod et sont type :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
create vue Vue_Gencod as
select *
from Gencod g
inner join Type_Gencod  t on (g.type_id = t.type_id)

La requete devient :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
select * 
from Collecte c
left outer join Vue_Gencod v on (v.gencod = c.gencod)

Plus simple, et je peux filtrer dans la vue uniqement les colonnes dont le module 2 a besoin.

La colonne gencod est indexé, l'index est bien utilisé dans la premiere requete sans la vue.

Avec la vue, il fait un full scan sur la table Gencod, du coup les performances sont tres médiocre.

Par contre si je fait un inner:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
select * 
from Collecte c
inner join Vue_Gencod v on (v.gencod = c.gencod)

La l'index est bien utilisé et c'est rapide.

Voilà, j'espère avoir été assez précis