oracle用户和方案的区别,用户和Oracle中的架构之间的区别？

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

+1我也一直想知道区别：-/。

下面有一篇有趣的文章可以消除所有疑问：http://radiofreetooting.blogspot.com/2007/02/user-schema.html

Oracle模式类似于Windows OS中的"我的文档"文件夹。 用户可以向其他用户授予权限，以查看其架构中的内容。 Oracle模式本质上是一个用户工作区。

在DBA上也进行了讨论：dba.stackexchange.com/questions/37012/。

从问汤姆

您应该将模式视为用户帐户并包含其中所有对象的集合

作为用于所有意图和目的的模式。

SCOTT是一种架构，包括具有各种授权的EMP，DEPT和BONUS表，以及

其他的东西。

SYS是一个包含大量表，视图，授权等的模式。

SYSTEM是一个架构.....

从技术上讲-模式是数据库使用的一组元数据(数据字典)，

通常使用DDL生成。模式定义数据库的属性，例如

表，列和属性。数据库模式是对数据库中数据的描述。

数据库。

在同一页面上：出于所有意图和目的，只需考虑user = schema = user = schema =同一件事。

但是我可以让两个用户使用相同的架构吗？

如果您的意思是"一个架构中的对象可以被多个用户拥有"，则答案为否。如果您的意思是"一个架构中的对象可以被多个用户使用"，那么答案肯定是"是"。

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

Oracle的模式(如Nebakanezer的回答所述)：基本上是一个用户帐户拥有的所有表和其他对象的集合，因此大致相当于一个用户帐户

常规模式：组成给定系统/应用程序的数据库的所有表，存储过程等的集合(如"开发人员应与DBA讨论新应用程序的模式"。)

意义2中的模式与意义1中的模式相似，但不相同。对于使用多个数据库帐户的应用程序，意义2中的模式可能包含多个Oracle模式：-)。

架构也可能意味着在其他情况下(例如在数学中)的其他许多不相关的事物。

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

@djangofan Afaik这个问题是关于Oracle的，而不是关于MS SQL的。

来自WikiAnswers：

模式是数据库对象的集合，包括表，视图，序列，存储过程，同义词，索引，集群和数据库链接等逻辑结构。

用户拥有架构。

用户和架构具有相同的名称。

CREATE USER命令创建一个用户。它还会自动为该用户创建一个架构。

CREATE SCHEMA命令不会像它暗示的那样创建"模式"，它仅允许您在单个事务中创建多个表和视图并在您自己的模式中执行多个授予。

出于所有意图和目的，您可以将用户视为架构，将架构视为用户。

此外，如果用户具有访问权限，则他们可以访问除其自己之外的其他模式中的对象。

关于CREATE SCHEMA的要点-我认为该命令的名称选择错误！

" CREATE SCHEMA命令不会创建它所暗示的" schema""。我认为有99％的困惑来自此。这个句子片段很好地清除了它。谢谢。

关于CREATE SCHEMA的注释：" Oracle有它，因为ANSI标准说它必须存在。"

我认为这是最好的答案。

像平常一样考虑用户(具有登录名和访问系统中某些对象权限的用户名/密码)，以及将模式作为用户主目录的数据库版本。用户" foo"通常在模式" foo"下创建事物，例如，如果用户" foo"创建或引用表" bar"，则Oracle将假定用户的意思是" foo.bar"。

简洁的描述，但是为什么您要同时为用户和架构使用" foo"？他们必须一样吗？

在Oracle中，USER是帐户名，SCHEMA是该用户拥有的对象集。即使，Oracle在CREATE USER语句的一部分中创建SCHEMA对象，并且SCHEMA与USER具有相同的名称，但是它们具有相同的含义。当然，混淆的部分原因在于USER和SCHEMA之间存在一对一的对应关系，并且用户模式共享其名称。

这个答案并没有定义所有者和架构之间的区别，但是我认为这增加了讨论的范围。

在我的思考世界中：

我一直在创建N个用户，我希望这些用户中的每一个"消费"(也就是使用)单个架构的想法使我感到困惑。

oracle-base.com上的Tim演示了如何执行此操作(拥有N个用户，并且这些用户中的每一个将被"重定向"到单个模式。

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

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.

请注意，使用角色可能无法解决PL / SQL代码的权限问题。运行存储过程时，不会以直观的方式传播对角色的对象授予。但是，我赞成这个答案，因为这种方法确实很棒，但据我所知，它鲜为人知，很少使用。

非常简单

If USER has OBJECTS

then call it SCHEMA

else

call it USER

end if;

可以授予用户访问不同用户拥有的架构对象的权限。

实际上，当人们打电话给用户时，会造成混乱。由于用户可能不是您所解释的架构。用户可以简单地是访问某些其他用户架构的用户。

模式是关于一个想法/领域的DB.object的封装，由一个用户拥有。然后它将被角色被禁止的其他用户/应用程序共享。因此，用户不需要拥有架构，但是架构需要具有所有者。

--USER和SCHEMA

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

--User用户是连接数据库(服务器)的帐户。我们可以使用CREATE USER用户名IDENTIFIED BY密码创建用户。

--schema

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

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

我们可以使用DROP SCHEMA schama_name RESTRICT语句来删除架构，但是它不能删除包含对象的脚本，因此要删除架构，它必须为空。此处的限制词强制指定了没有对象的架构。

如果尝试在其架构中删除用户包含对象，则必须指定CASCADE字，因为oracle不允许您删除用户包含对象。

DROP USER用户名CASCADE

因此oracle删除架构中的对象，然后自动删除用户。从其他架构(例如视图和私有同义词)引用此架构对象的对象将变为无效状态。

我希望现在你们之间有所区别，如果您对此主题有任何疑问，请随时提出。

谢谢。

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

而模式是数据库对象的封装。就像房屋的所有者拥有房屋中的所有物品一样，只有拥有者(即架构)为其提供了必要的授权，用户帐户才能访问房屋中的商品。

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

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

用户：访问数据库资源。就像一把钥匙进入房子。

模式：收集有关数据库对象的信息。像书中的索引一样，其中包含有关本章的简短信息。

在这里查看详细信息

根据我对Oracle的一点了解，USER和SCHEMA有点相似。但是也有很大的不同。如果" USER"拥有任何对象，则可以将USER称为SCHEMA，否则...它将仅保留为" USER"。一旦用户拥有至少一个对象，然后根据上面的所有定义，...用户现在可以称为SCHEMA。

模式用户和数据库用户是相同的，但是如果模式拥有数据库对象，并且他们可以执行其对象的任何操作，但用户只能访问对象，那么在模式用户赋予您适当的特权之前，他们不能执行任何DDL操作。

好吧，我在某处读到，如果您的数据库用户具有DDL特权，则它是模式，否则是用户。

这实际上是一个有用的区别-具有CREATE privs的用户与没有CREATE privs的用户不同

模式是对象的容器。

它归用户所有。

这意味着用户可以拥有多个架构。我不认为这可能(在Oracle中)；尽管用户A可能具有对模式B的完全管理权限，但即使没有人使用这样的用户名登录，后者也将始终由用户B拥有。