如何使删除并重新创建的表的 GRANT 持续存在?

发布于 2024-09-02 23:30:09 字数 647 浏览 4 评论 0原文

我正在进行一个相当新的项目,我们仍在修改 Oracle 11g 数据库表的设计。因此,我们经常删除并重新创建表,以确保每当我们进行更改时,表创建脚本都能按预期工作。

我们的数据库由 2 个模式组成。一个模式有一些带有 INSERT 触发器的表,这会导致数据有时被复制到第二个模式中的表中。这需要我们使用管理员帐户(例如sysdba)登录数据库,并GRANT将第一个模式的访问权限授予第二个模式上的必要表,例如

GRANT ALL ON schema_two.SomeTable TO schema_one;

我们的问题是每次我们对数据库设计进行更改并想要删除并重新创建数据库表时,当表被删除时,我们 GRANT 授予 schema_one 的访问权限就会消失。掉了。因此,这会产生另一个烦人的步骤,其中每次删除并重新创建其中一个表时,我们都必须使用管理员帐户登录才能重新授予访问权限。

这不是什么大问题,但我希望从我们的开发和测试过程中消除尽可能多的步骤。有没有什么方法可以GRANT访问表,使得GRANT权限在表被删除然后重新创建后仍然存在?如果这是不可能的,那么是否有更好的方法来解决这个问题?

I'm on a fairly new project where we're still modifying the design of our Oracle 11g database tables. As such, we drop and re-create our tables fairly often to make sure that our table creation scripts work as expected whenever we make a change.

Our database consists of 2 schemas. One schema has some tables with INSERT triggers which cause the data to sometimes be copied into tables in our second schema. This requires us to log into the database with an admin account such as sysdba and GRANT access to the first schema to the necessary tables on the second schema, e.g.

GRANT ALL ON schema_two.SomeTable TO schema_one;

Our problem is that every time we make a change to our database design and want to drop and re-create our database tables, the access we GRANT-ed to schema_one went away when the table was dropped. Thus, this creates another annoying step wherein we must log in with an admin account to re-GRANT the access every time one of these tables is dropped and re-created.

This isn't a huge deal, but I'd love to eliminate as many steps as possible from our development and testing procedures. Is there any way to GRANT access to a table in such a way that the GRANT-ed permissions survive a table being dropped and then re-created? And if this isn't possible, then is there a better way to go about this?

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

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

发布评论

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

评论(5

只怪假的太真实 2024-09-09 23:30:09

因此,授权被撤销的原因是新表是一个不同的对象。

SQL> select object_id from user_objects
  2  where object_name = 'T72'
  3  /

 OBJECT_ID
----------
    659195

SQL> drop table t72
  2  /

Table dropped.

SQL> create table t72 (id number)
  2  /

Table created.

SQL> select object_id from user_objects
  2  where object_name = 'T72'
  3  /

 OBJECT_ID
----------
    659212

SQL>

授权是针对对象的,而不是对象的名称。

我不明白你的问题是这样的:你有一个删除并重新创建 schema_two 中的表的过程。为什么该进程不向 schema_one 授予这些表的授予权限?为什么你有一个管理员帐户来代替呢?我假设您正在作为 schema_two 连接来运行 DROP 和 CREATE 语句。为什么不直接将 GRANT 语句添加到该步骤中呢?

因为授予对象权限与创建表一样是安装的一部分。所以你应该有一个可以完成所有事情的流程。

So the reason why the grants get revoked is that the new table is a different object.

SQL> select object_id from user_objects
  2  where object_name = 'T72'
  3  /

 OBJECT_ID
----------
    659195

SQL> drop table t72
  2  /

Table dropped.

SQL> create table t72 (id number)
  2  /

Table created.

SQL> select object_id from user_objects
  2  where object_name = 'T72'
  3  /

 OBJECT_ID
----------
    659212

SQL>

The grants are on the object, not the object's name.

What I don't understand about your problem is this: you have a process which drops and re-creates the tables in schema_two. Why doesn't that process also grant grant privileges on those tables to schema_one? Why do you have an admin account do it instead? I presume you are connecting as schema_two to run the DROP and CREATE statements. Why not just add the GRANT statements to that step?

Because granting privileges on objects is as much a part of the installation as creating the tables. So you ought to have a process which does everything.

乞讨 2024-09-09 23:30:09

您可以将选择任何表插入任何表等授予schema_one,但这似乎有点矫枉过正,并且不会反映您在生产中所做的事情(希望如此)。为什么不能在创建表的同时以 schema_two 身份登录时发出授权?我总是在创建脚本中这样做,并且只需要使用管理员帐户来授予第三方或系统权限。我怀疑我错过了什么...

You could grant select any table, insert any table, etc to schema_one, but that seems like overkill and won't reflect what you do in production (hopefully). Why can't you issue the grant at the same time as you create the table, while logged in as schema_two? I've always done that in the creation scripts, and only ever had to use an admin account to grant third-party or system privs. I suspect I'm missing something...

许久 2024-09-09 23:30:09

您正在做什么 ALTER TABLE 语句无法处理的事情?

下一个最佳选择可能是创建一个引用偶尔消失的表的视图 - 该视图不会消失,如果在这种情况下该表不存在,您只会收到错误。 IE:

CREATE VIEW table_vw AS
  SELECT t.* 
    FROM DISAPPEARING_TABLE t

使用 * 符号还意味着您不必不断更新视图来公开表中的列。

What are you doing that couldn't be handled by ALTER TABLE statements?

The next best option might be to create a view that references the table that occaisionally disappears - the view won't disappear, you'd just get an error if the table doesn't exist in such a situation. IE:

CREATE VIEW table_vw AS
  SELECT t.* 
    FROM DISAPPEARING_TABLE t

Using * notation would also mean you don't have to continually update the view to expose columns in the table.

靖瑶 2024-09-09 23:30:09

您可以有一个 DDL 触发器或一个每隔几分钟运行一次的批处理作业,自动授予权限。但这是一个安全漏洞,并不代表生产。

You could have a DDL trigger or a batch job that runs every few minutes that grants privileges automatically. But that is a bit of a security hole and won't represent production.

苏大泽ㄣ 2024-09-09 23:30:09

我建议您也可以为用于创建表的帐户提供运行拨款的能力。

分享并享受。

I suggest that you might give the account which you use to create the tables the ability to run the grants as well.

Share and enjoy.

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