Les synonymes publics ont un but très spécifique; ils permettent à un objet d'être référencé par tous utilisateur - en supposant qu'il dispose des privilèges appropriés. Si, à l'avenir, vous souhaitez modifier la façon dont un utilisateur spécifique visualise un objet, les synonymes publics ne sont pas la solution.
Ils utilisent également un nom d'objet spécifique pour l'ensemble de la base de données. Cependant, le fait qu'un synonyme public existe ne vous empêche pas de créer un objet avec le même nom. Cela peut être incroyablement déroutant.
Par exemple, supposons que vous ayez une procédure test et un schéma emp . Essayer d'exécuter emp.test ne fonctionnera pas car vous avez déjà un synonyme public emp sur la table .
Tom Kyte , semble ont écrit un nombre d'articles à ce sujet.
En ce qui concerne les performances, ils semblent suggérer qu'un synonyme public sur un synonyme privé entraînera un légère diminution des performances . Cependant, l'utilisation d'un synonyme au lieu d'aucun synonyme entraînera également une légère diminution des performances. Cela suggère que si chaque dernier computron est précieux, vous ne devriez pas du tout utiliser de synonymes.
Mis ensemble, je pense que cela signifie que vous devriez éviter les synonymes publics si possible. Si vous avez besoin on en utilise bien sûr un, ils existent pour une raison après tout, mais si ce n'est pas le cas, à quoi bon en avoir un? Le scott.emp est clair, vous montre exactement à quel schéma et objet vous faites référence sans aucune possibilité d'interprétation erronée, que ce soit par vous-même ou par quelqu'un d'autre qui découvre la base de données et le code.
Point rapide. Vous ne le dites pas explicitement, mais le libellé de votre question semble suggérer que vous créez un schéma pour chaque utilisateur. Cela semble être extrêmement déroutant...
