Pouvez-vous utiliser les espaces table oracle comme variable

Question

Je suis nouveau à Oracle, j'ai deux tablespaces un pour le dev et un pour le live.

Y a-t-il un moyen pour que je puisse avoir une variable sur un en-tête de paquet qui contient un nom d'espace de table, qui peut alors être utilisé à partir des procédures définies dans l'en-tête du paquet?

Je dois faire cela car j'ai un tableSpace (TableSpaceA) qui doit interroger des tables dans TableSpaceB via des procédures. La Dev TableSpaceB a un nom différent de l'espace de table pour vivre donc j'espérais pouvoir déclarer dans le paquet d'en-tête une variable comme

Tablespace temp = "TableSpaceName"
Puis
Select * from temp.TableName

Et enfin changer « nom_espace_table » quand je roule ma changements à l'environnement en direct?

Answer 1

Les tablespaces sont une solution administrative: elles permettent de regrouper logiquement le stockage sans avoir à se préoccuper des chemins de fichiers ou d'autres administrateurs.

---

De votre question révisée, il est évident que Tony est juste et ce que vous entendez est schéma.

Un schéma est l'ensemble des objets appartenant à un utilisateur. Lorsqu'une procédure appartenant à l'utilisateur A doit référencer un objet appartenant au schéma B, il existe deux façons de le faire. La première consiste à coder en dur le nom du schéma.

select * 
from user_b.emp; 

C'est généralement bien, mais ne fonctionnera pas dans le scénario que vous décrivez, où l'autre schéma a un nom différent nom différent dans d'autres environnements (C plutôt que B).

Le problème consiste à utiliser des synonymes.

select * 
from not_my_emp; 

En DEV le synonyme serait:

create synonym not_my_emp for user_b.emp 
/

alors que dans la production, il serait

create synonym not_my_emp for user_c.emp 
/

Le tableau pourrait même avoir une autre table dans la production, il n'a pas d'importance . Le synonyme sert d'interface pour protéger nos objets des détails désordonnés des autres schémas.

Notez qu'un synonyme n'accorde pas de privilèges sur l'objet sous-jacent. Cela signifie que USER_B doit accorder des privilèges sur EMP en développement et que USER_C doit accorder des privilèges dans Production.