synonymes

bonjour,

je voudrais s'il vous plait mieux connaitre l'utilité des synonymes

merci

Bonjour,


Quand tu essaies d'accéder à un objet qui appartient à un autre schéma, tu es obligé de préciser le nom de l'objet de la forme suivante : propriétaire.objet
Dans ce cas, un synonyme est une sorte d'alias, il te suffit d'indiquer le nom de ton synonyme au lieu du nom de l'objet complètement qualifé.

Tu as des synonymes qui sont privés (ie n'appartiennent qu'a ton compte Oracle) et d'autre qui sont publiques (ie visible par tout les comptes Oracle).

Une autre utilisation possible est quand tu remplaces une table (TTOTO) par une vue (VTOTO), un synonyme TTOTO pointant vers VTOTO te permet d'éviter d'adapter ton code.


Laly.

Pour faire une analogie avec le système, un synonyme, c'est exactement comme un "raccourci" sour Windows ou un lien symbolique sous Nux : c'est une autre façon, en générale plus rapide, de nommer un objet mais sans que cela ne donne de droits dessus.

un synonyme permet aussi de référencer une table dans une autre base

Code:

---

1 2 3 4 5 6

SQL> create or replace synonym scott.emp for scott.emp@db01.us.oracle.com;   Synonym created. SQL> create or replace synonym scott.emp for scott.emp@db01.eu.oracle.com;   Synonym created.

---

alors je voudrais svp qu'on discute ce cas

on a 3 schema différent qui ont des tables avec le meme nom (certaine tables) et cela suit aune mauvaise conception ou autre

schema1(table1, table2, table3,........)
schema2(table1, table2, table3,........)
schema3(table1, table2, table3,........)

on a eu besoin de creer des synonymes sachant qu'on peut pas toucher au code et que le nom du synonyme doit etre identique au nom de la table alors

pour le schema1 on creer des synonymes publics pour les tables : table1, table2, table3

par ce que pour le schema2 on peux pas faire la meme chose on a creer des synonymes privée pour chaque utilisateur "penible"

mais qu'est ce qu'on va faire pour le schema3 si le deux schema (2 et 3) ont des utilisateur en commun

Tu devrais expliciter un peu plus ton problème ...

A vu de nez , je pense qu'il vaut mieux passer par l'instruction :

alter session set current_schema = nom_du_schema;


En gros, lorsque ton user se connecte, tu lances :

conn toto/toto@base

alter session set current_schema=SCHEMA1;

==> vérification :
select sys_context('userenv','current_schema') x from dual ;

(si ce toto ne doit voir que les tables de schema1)

Parallélement à cela pour que cela marche , il faudra que ton user dispose de droit sur les tables de schema1 :
grant select, insert, update, delete ....