当前位置：文江博客话题详情

Oracle 中用户和模式之间的区别？

发布于 2024-07-21 02:18:40 字数 27 浏览 5 评论 0原文

Oracle 中的用户和模式有什么区别？

原文

分享到QQ

分享到微博

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

发布评论

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

昵称有卵用 2024-07-28 02:18:41

模式是对象的容器。
它由用户拥有。

回复收藏 0 原文

只有一腔孤勇 2024-07-28 02:18:41

好吧，我在某处读到，如果您的数据库用户具有 DDL 权限，那么它就是一个架构，否则它就是一个用户。

回复收藏 0 原文

淡墨 2024-07-28 02:18:40

来自询问 Tom

您应该将模式视为用户帐户和集合
其中的所有对象作为用于所有意图和目的的模式。
SCOTT 是一个包含 EMP、DEPT 和 BONUS 表的架构
各种补助金和其他东西。
SYS 是一个包含大量表、视图、授权等的架构
等等
SYSTEM 是一个模式......
从技术上讲——模式是使用的元数据（数据字典）集
由数据库生成，通常使用 DDL 生成。模式定义
数据库的属性，例如表、列和属性。
数据库架构是数据库中数据的描述。

回复收藏 0 原文

浅忆 2024-07-28 02:18:40

我认为问题在于 Oracle 使用的术语“架构”与通常的含义略有不同。

Oracle的模式（如Nebakanezer的答案中所解释的）：基本上是用户帐户拥有的所有表和其他对象的集合，因此大致相当于用户帐户
一般模式：组成数据库的所有表、存储过程等的集合对于给定的系统/应用程序（如“开发人员应该与 DBA 讨论我们新应用程序的架构。”）

意义 2 中的架构类似，但与意义 1 中的架构不同。例如，对于使用多个数据库帐户，意义 2 中的模式可能由多个 Oracle 模式组成:-)。

另外，模式还可以表示其他上下文中（例如数学）中的一堆其他相当不相关的事物。

Oracle 应该只使用“userarea”或“accountobjects”之类的术语，而不是重载“schema”...

回复收藏 0 原文

嗫嚅 2024-07-28 02:18:40

来自 WikiAnswers：

模式是数据库对象的集合，包括表、视图、序列等逻辑结构、存储过程、同义词、索引、集群和数据库链接。
用户拥有一个模式。
用户和模式具有相同的名称。
CREATE USER 命令创建一个用户。它还会自动为该用户创建一个架构。
CREATE SCHEMA 命令并不像它所暗示的那样创建“架构”，它只是允许您创建多个表和视图，并在单个事务中在您自己的架构中执行多个授权。
出于所有意图和目的，您可以将用户视为模式，将模式视为用户。

此外，如果用户有权限的话，他们还可以访问自己架构之外的对象。

回复收藏 0 原文

秋心╮凉 2024-07-28 02:18:40

像平常一样将用户（有权登录并访问系统中的某些对象的用户名/密码）和模式视为用户主目录的数据库版本。用户“foo”通常在模式“foo”下创建事物，例如，如果用户“foo”创建或引用表“bar”，那么Oracle将假定该用户意味着“foo.bar”。

回复收藏 0 原文

比忠 2024-07-28 02:18:40

这个答案没有定义所有者和模式之间的区别，但我认为它增加了讨论。

在我的小思考世界中：

我一直在努力思考创建 N 个用户，我希望这些用户中的每一个“消费”（也称为使用）单个模式。

oracle-base.com 上的 Tim 展示了如何执行此操作（有 N 个用户，每个用户都将被“重定向”到单个模式。

他有第二种“同义词”方法（此处未列出）。我在这里仅引用 CURRENT_SCHEMA 版本（他的方法之一）：

CURRENT_SCHEMA 方法
此方法使用 CURRENT_SCHEMA 会话属性自动
将应用程序用户指向正确的架构。
首先，我们创建架构所有者和应用程序用户。
CONN 系统/密码 AS SYSDBA 

  -- 删除现有的同名用户和角色。 
  删除用户 schema_owner CASCADE； 
  删除用户 app_user 级联； 
  删除角色 schema_rw_role； 
  删除角色 schema_ro_role； 

  -- 模式所有者。 
  创建用户 schema_owner 由密码识别 
    默认表空间用户 
    临时表空间温度 
    用户配额无限； 

  授予连接，为 schema_owner 创建表； 

  ——应用程序用户。 
  创建用户 app_user 由密码识别 
    默认表空间用户 
    临时表空间温度； 

  授予连接到app_user； 
  
请注意，应用程序用户可以连接，但没有任何权限
表空间配额或创建对象的权限。
接下来，我们创建一些角色以允许读写和只读访问。
创建角色 schema_rw_role; 
  创建角色 schema_ro_role； 
  
我们希望为应用程序用户提供对架构的读写访问权限
对象，因此我们授予相关角色。
将 schema_rw_role 授予 app_user； 
  
我们需要确保应用程序用户拥有其默认架构
指向架构所有者，因此我们创建一个 AFTER LOGON 触发器来
为我们做这件事。
创建或替换触发器 app_user.after_logon_trg 
  登录 app_user.SCHEMA 后 
  开始 
    DBMS_APPLICATION_INFO.set_module(USER, '初始化'); 
    立即执行 'ALTER SESSION SET current_schema=SCHEMA_OWNER'; 
  结尾; 
  / 
  
现在我们准备在架构所有者中创建一个对象。
CONN schema_owner/密码 

  创建表 test_tab ( 
    身份证号码， 
    描述 VARCHAR2(50), 
    约束 test_tab_pk 主键（id） 
  ）； 

  将 test_tab 上的选择授予 schema_ro_role； 
  将 test_tab 上的选择、插入、更新、删除授予 schema_rw_role； 
  
注意如何将权限授予相关角色。没有
这样，应用程序用户将看不到这些对象。我们现在
拥有正常运行的架构所有者和应用程序用户。
SQL>   CONN 应用程序_用户/密码 
  连接的。 
  SQL>   DESC 测试_选项卡 
   名字为空？   类型 
   -------------------------------------------------- --- -------- ------------------------------------ 
   ID 不为空号码 
   描述 VARCHAR2(50) 

  SQL> 
  
当应用程序用户只是一个简单的用户时，此方法是理想的选择。
主模式的替代入口点，不需要任何对象
它自己的。

This answer does not define the difference between an owner and schema but I think it adds to the discussion.

In my little world of thinking:

I have struggled with the idea that I create N number of users where I want each of these users to "consume" (aka, use) a single schema.

Tim at oracle-base.com shows how to do this (have N number of users and each of these users will be "redirected" to a single schema.

He has a second "synonym" approach (not listed here). I am only quoting the CURRENT_SCHEMA version (one of his approaches) here:

CURRENT_SCHEMA Approach
This method uses the CURRENT_SCHEMA session attribute to automatically
point application users to the correct schema.
First, we create the schema owner and an application user.
CONN sys/password AS SYSDBA

-- Remove existing users and roles with the same names.
DROP USER schema_owner CASCADE;
DROP USER app_user CASCADE;
DROP ROLE schema_rw_role;
DROP ROLE schema_ro_role;

-- Schema owner.
CREATE USER schema_owner IDENTIFIED BY password
  DEFAULT TABLESPACE users
  TEMPORARY TABLESPACE temp
  QUOTA UNLIMITED ON users;

GRANT CONNECT, CREATE TABLE TO schema_owner;

-- Application user.
CREATE USER app_user IDENTIFIED BY password
  DEFAULT TABLESPACE users
  TEMPORARY TABLESPACE temp;

GRANT CONNECT TO app_user;
Notice that the application user can connect, but does not have any
tablespace quotas or privileges to create objects.
Next, we create some roles to allow read-write and read-only access.
CREATE ROLE schema_rw_role;
CREATE ROLE schema_ro_role;
We want to give our application user read-write access to the schema
objects, so we grant the relevant role.
GRANT schema_rw_role TO app_user;
We need to make sure the application user has its default schema
pointing to the schema owner, so we create an AFTER LOGON trigger to
do this for us.
CREATE OR REPLACE TRIGGER app_user.after_logon_trg
AFTER LOGON ON app_user.SCHEMA
BEGIN
  DBMS_APPLICATION_INFO.set_module(USER, 'Initialized');
  EXECUTE IMMEDIATE 'ALTER SESSION SET current_schema=SCHEMA_OWNER';
END;
/
Now we are ready to create an object in the schema owner.
CONN schema_owner/password

CREATE TABLE test_tab (
  id          NUMBER,
  description VARCHAR2(50),
  CONSTRAINT test_tab_pk PRIMARY KEY (id)
);

GRANT SELECT ON test_tab TO schema_ro_role;
GRANT SELECT, INSERT, UPDATE, DELETE ON test_tab TO schema_rw_role;
Notice how the privileges are granted to the relevant roles. Without
this, the objects would not be visible to the application user. We now
have a functioning schema owner and application user.
SQL> CONN app_user/password
Connected.
SQL> DESC test_tab
 Name                                                  Null?    Type
 ----------------------------------------------------- -------- ------------------------------------
 ID                                                    NOT NULL NUMBER
 DESCRIPTION                                                    VARCHAR2(50)

SQL>
This method is ideal where the application user is simply an
alternative entry point to the main schema, requiring no objects of
its own.

回复收藏 0 原文

战皆罪 2024-07-28 02:18:40

这很简单。

If USER has OBJECTS
then call it SCHEMA
else
     call it USER
end if;

用户可以被授予对不同用户拥有的模式对象的访问权。

It's very simple.

If USER has OBJECTS
then call it SCHEMA
else
     call it USER
end if;

A user may be given access to schema objects owned by different Users.

回复收藏 0 原文

乖乖兔^ω^ 2024-07-28 02:18:40

模式是关于感兴趣的想法/领域的 DB.objects 的封装，并由一个用户拥有。然后，它将由具有受抑制角色的其他用户/应用程序共享。因此，用户不需要拥有模式，但模式需要有所有者。

回复收藏 0 原文

感性不性感 2024-07-28 02:18:40

--USER 和 SCHEMA

用户和模式这两个词是可以互换的，这就是为什么大多数人对这个词感到困惑，下面我解释了它们之间的区别

--User 用户是连接数据库（服务器）的帐户。我们可以使用 CREATE USER user_name IDENTIFIED BY password 来创建用户。

--Schema

实际上Oracle数据库包含处理数据的逻辑和物理结构。Schema也是处理数据库（内存组件）中数据的逻辑结构。它是在创建用户时由 oracle 自动创建的。它包含由与该模式关联的用户创建的所有对象。例如，如果我创建了一个名为 santhosh 的用户，那么 oracle 创建了一个名为 santhosh 的模式，oracle 将用户 santhosh 创建的所有对象存储在 santhosh 中架构。

我们可以通过 CREATE SCHEMA 语句创建模式，但是 Oracle 会自动为该模式创建用户。

我们可以使用 DROP SCHEMA scama_name RESTRICT 语句删除模式，但它不能删除包含对象的模式，因此要删除模式，它必须为空。这里的限制字强制指定不包含对象的模式。

如果我们尝试删除用户架构中的包含对象，我们必须指定 CASCADE 单词，因为 Oracle 不允许删除用户包含对象。
DROP USER 用户名 CASCADE
因此，oracle 删除模式中的对象，然后自动删除用户，从其他模式（如视图和私有同义词）引用此模式对象的对象将进入无效状态。

回复收藏 0 原文

冰雪之触 2024-07-28 02:18:40

基于我对 Oracle 的一点了解......用户和架构有点相似。但也有一个重大区别。如果“用户”拥有任何对象，则用户可以称为模式，否则......它将仅保留为“用户”。一旦用户拥有至少一个对象，那么根据上面的所有定义......用户现在可以称为模式。

回复收藏 0 原文

怀中猫帐中妖 2024-07-28 02:18:40

用户帐户就像持有您家钥匙的亲戚，但不拥有任何东西，即用户帐户不拥有任何数据库对象...没有数据字典...

而模式是数据库对象的封装。这就像房子的主人拥有你房子里的所有东西，只有当主人（即模式）向它提供所需的补助时，用户帐户才能够访问家里的物品。

回复收藏 0 原文

ζ澈沫 2024-07-28 02:18:40

对于大多数更熟悉 MariaDB 或 MySQL 的人来说，这似乎不太令人困惑，因为在 MariaDB 或 MySQL 中，它们具有不同的模式（包括不同的表、视图、PLSQL 块和数据库对象等），而 USERS 是可以访问这些模式的帐户。架构。因此，没有特定的用户可以属于任何特定的模式。必须向该架构授予权限，然后用户才能访问它。在 MySQL 和 MariaDB 等数据库中，用户和架构是分开的。

在 Oracle 中，模式和用户几乎被视为相同。要使用该模式，您需要拥有权限，您会觉得模式名称只是用户名。可以跨模式授予权限，以从不同模式访问不同的数据库对象。在 Oracle 中，我们可以说用户拥有模式，因为当您创建用户时，您会为其创建数据库对象，反之亦然。

回复收藏 0 原文