Discussion :

[Oraman]

j'ai un schéma dans une base content 1465 tables.
pour certaines raison (décision du boss dont j'ignore le motif) je serai ramener à répatir ces tables (ainsi que l'ensembles des objets bien évidement) entre au moins deux schéma
donc j'auria des jointure inter schéma et des contarines d'integrité (FK) inter shéma etc...
quel impact aurait cette opération côté performance ?
et y a-t-il des incovénients d'ordre général ?
la décision n'est pas totalemnt prise alors s'il y a de gros incovénients il faut que je puisse argumenter
avez vous une idée ?

[orafrance]

pas d'inconvénient, faut juste que les schémas aient des droits suffisant pour faire les jointures et puis c'est tout... aucun souci

[Oraman]

merci Fred
mais franchemanet ça me parait pas beau d'implementer un même schéma conceptuel sur plusieurs shema de la base. en plus au niveau des requêtes inter schema on doit appeler la table précédé de son shéma (ex : scott.employe) et ça sera comme ça dans le code des procdures stockées ... donc si un jour on doit changer de nom de l'un des schéma au moins (ex :shéma test et schéma prod sur une même instance ) ça sera trop complexe et on est ramené a modifier le code des requêtes et des procédures...
je ne sais pas si vous voyez les choses autrement??
j'aimerai bien etudier le sujet dans tout les sens avant de m'aventurer dans cette dmarche de repartition ? et surtout de bien evaluer les risques s'il y en a

[LeoAnderson]

Non, regardez les bases demo d'oracle : il y a les schéma HR, OE, .... qui contiennent chacun des domaines fonctionnels disctints même s'il y a des liens entre les différentes parties.

C'est plus propre en général plutôt que d'avoir un schéma qui contient tout.

Par contre, ce qui m'inquiète c'est plus le boss qui prend des décisions techniques sans que la personne en charge de la base n'en sache le pourquoi..

[orafrance]

merci Fred
mais franchemanet ça me parait pas beau d'implementer un même schéma conceptuel sur plusieurs shema de la base. en plus au niveau des requêtes inter schema on doit appeler la table précédé de son shéma (ex : scott.employe) et ça sera comme ça dans le code des procdures stockées ... donc si un jour on doit changer de nom de l'un des schéma au moins (ex :shéma test et schéma prod sur une même instance ) ça sera trop complexe et on est ramené a modifier le code des requêtes et des procédures...

Pour éviter les problèmes de ce genre on crée des synonymes et ainsi le code ne porte pas le nom des schémas

Et effectivement, faire ce genre de modification sans savoir pourquoi c'est s'amputer du rôle de conseil qu'on est tenu d'avoir

[Oraman]

Par contre, ce qui m'inquiète c'est plus le boss qui prend des décisions techniques sans que la personne en charge de la base n'en sache le pourquoi..

Et effectivement, faire ce genre de modification sans savoir pourquoi c'est s'amputer du rôle de conseil qu'on est tenu d'avoir

oui c'est ce qui m'énérve le plus dans cette histoire
en ce qui me concerne je suis entrain d'étudier le sujet (merci pour votre aide) et s'il y qq chose qui cloche c'est de mon devoir de le signaler

Pour éviter les problèmes de ce genre on crée des synonymes et ainsi le code ne porte pas le nom des schémas

FRED tu veux dire les public synonyme sur tout les objets?
docn c'est comme si on a tout les objets sous le public donc c'est comme si on revient à la position initiale qui est d'avoir touts les objets sur un même schéma

[orafrance]

c'est bien ça mais ça empêche pas de mettre des droits sur les tables... c'est juste la vision utilisateur qui est impactée