可以像变量一样使用oracle表空间吗

发布于 2024-09-13 04:08:36 字数 346 浏览 6 评论 0原文

我是 Oracle 新手,我有两个表空间,一个用于开发,一个用于实时。

有没有一种方法可以在包头中包含一个包含表空间名称的变量,然后可以在包头中定义的过程中使用该变量?

我需要执行此操作,因为我有一个表空间 (TableSpaceA) 需要通过过程查询 TableSpaceB 中的表。 Dev TableSpaceB 有一个不同的表空间名称,因此我希望可以在包头中声明一个像

这样的变量 表空间温度=“表空间名称”
然后
<代码> 从 temp.TableName 中选择 * ?

当我将更改发布到实时环境时,最后更改“TableSpaceName”

I am new to Oracle, I have two tablespaces one for dev and one for live.

Is there a way that I can have a variable on a Package header that contains a tablespace name, which can then be used from within the procedures defined in the package header?

I need to do this as I have one tableSpace (TableSpaceA) that needs to query tables in TableSpaceB via procedures. The Dev TableSpaceB has a different table space name to live therefore I was hoping I could declare in the Package header a variable like


Tablespace temp = "TableSpaceName"

Then

Select * from temp.TableName

And finally change "TableSpaceName" when i roll my changes out to the live environment?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

吻风 2024-09-20 04:08:36

表空间是一个管理事物:它们是一种对存储进行逻辑分组的方式,无需担心文件路径或其他管理问题。


从您修改后的问题来看,显然托尼是对的,您的意思是模式

模式是用户拥有的一组对象。当用户 A 拥有的过程需要引用架构 B 拥有的对象时,有两种方法可以实现此目的。第一种方法是对架构名称进行硬编码。

select * 
from user_b.emp;

这通常很好,但在您描述的场景中不起作用,其中其他模式在其他环境(C 而不是 B)中具有不同的名称。

解决这个问题的方法是使用同义词。

select * 
from not_my_emp;

在 DEV 中,同义词是:

create synonym not_my_emp for user_b.emp
/

而在生产中则是

create synonym not_my_emp for user_c.emp
/

该表甚至可以在生产中具有不同的表,但这并不重要。同义词充当一个接口,保护我们的对象免受其他模式的混乱细节的影响。

请注意,同义词不会授予底层对象的权限。这意味着 USER_B 必须在开发中授予 EMP 权限,而 USER_C 必须在生产中授予权限。

Tablespaces are an administrative thing: they are a way of logically grouping storage without the need to worry about filepaths or other administrivia.


From your revised question it is obvious that Tony is right and what you mean is schema.

A schema is the set of objects owned by a user. When a procedure owned by User A needs to reference an object owned by Schema B there are two ways of doing this. The first way is to hardcode the schema name.

select * 
from user_b.emp;

This is usually fine but will not work in the scenario you describe, where the other schema has a different name different name in other environments (C rather than B).

The way around this problem is to use synonyms.

select * 
from not_my_emp;

In DEV the synonym would be:

create synonym not_my_emp for user_b.emp
/

whereas in production it would be

create synonym not_my_emp for user_c.emp
/

The table could even have a different table in production, it doesn't matter. The synonym acts as an interface to shield our objects from the untidy details of other schemas.

Note that a synonym does not grant privileges on the underlying object. This means that USER_B has to grant privileges on EMP in Development and USER_C has to grant privileges in Production.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文