Synonimy publiczne służą bardzo konkretnemu celowi; umożliwiają odwoływanie się do obiektu przez każdy użytkownik - zakładając, że posiada odpowiednie uprawnienia. Jeśli w przyszłości zechcesz zmienić sposób, w jaki określony użytkownik widzi obiekt, publiczne synonimy nie są dobrym rozwiązaniem.
Używają również określonej nazwy obiektu dla całej bazy danych. Jednak fakt, że istnieje publiczny synonim, nie uniemożliwia utworzenia obiektu o tej samej nazwie. To może być niewiarygodnie mylące.
Załóżmy na przykład, że masz procedurę test i schemat emp . Próba wykonania emp.test nie będzie działać, ponieważ masz już publiczny synonim emp na stole .
Tom Kyte , wydaje się napisałem liczba artykułów o tym.
Jeśli chodzi o aspekt wydajności, zdają się sugerować, że publiczny synonim zamiast prywatnego synonimu spowoduje niewielki spadek wydajności . Jednak użycie synonimu zamiast braku synonimu spowoduje również niewielki spadek wydajności. Sugeruje to, że jeśli każdy ostatni komputron jest cenne, nie powinieneś w ogóle używać synonimów.
Podsumowując, myślę, że oznacza to, że powinieneś unikać publicznych synonimów, jeśli to możliwe. Jeśli potrzebujesz jeden, to oczywiście używaj jednego, w końcu istnieją z jakiegoś powodu, ale jeśli nie, to po co go mieć? scott.emp konstrukcja jest przejrzysta, pokazuje dokładnie, do jakiego schematu i obiektu się odwołujesz, bez możliwości błędnej interpretacji, zarówno przez Ciebie, jak i przez kogoś nowego w bazie danych i kodzie.
Szybki punkt. Nie mówisz tego wprost, ale sformułowanie twojego pytania wydaje się sugerować, że tworzysz schemat dla każdego użytkownika. Wygląda na to, że byłoby to bardzo mylące...
