从WikiAnswers:

A schema is collection of database objects, including logical structures such as tables, views, sequences, stored procedures, synonyms, indexes, clusters, and database links. A user owns a schema. A user and a schema have the same name. The CREATE USER command creates a user. It also automatically creates a schema for that user. The CREATE SCHEMA command does not create a "schema" as it implies, it just allows you to create multiple tables and views and perform multiple grants in your own schema in a single transaction. For all intents and purposes you can consider a user to be a schema and a schema to be a user.

此外，用户可以访问除自己的模式之外的模式中的对象，如果他们有权限这样做的话。

摘自《问汤姆》

您应该将模式视为用户帐户和其中所有对象的集合 作为所有意图和目的的模式。

SCOTT是一个包含EMP、DEPT和奖金表的模式，以及各种授权 其他的东西。

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

SYSTEM是一个模式.....

从技术上讲——模式是数据库使用的元数据(数据字典)的集合， 通常使用DDL生成。模式定义数据库的属性，例如 表、列和属性。数据库模式是数据库中数据的描述 数据库。

将用户视为您通常所做的(用户名/密码，具有登录和访问系统中某些对象的权限)，将模式视为用户主目录的数据库版本。用户“foo”通常在“foo”模式下创建东西，例如，如果用户“foo”创建或引用表“bar”，那么Oracle将假设用户指的是“foo.bar”。

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

我认为问题在于Oracle使用的术语模式与它的一般含义略有不同。

Oracle的模式(Nebakanezer的回答中解释过):基本上是一个用户帐户拥有的所有表和其他对象的集合，所以大致相当于一个用户帐户 一般模式:构成给定系统/应用程序数据库的所有表、scproc等的集合(如“开发人员应该与dba讨论我们新应用程序的模式”)。

概念2中的图式。是相似的，但不一样的模式在意义1。例如，对于一个使用多个数据库帐户的应用程序，意义2中的模式可能由几个Oracle模式组成:-)。

另外，图式在其他语境中也可以指其他一些不相关的东西(比如在数学中)。

Oracle应该使用“userarea”或“accountobjects”这样的术语，而不是重载“schema”……

模式和数据库用户是一样的，但如果模式拥有数据库对象，他们可以对对象做任何事情，但用户只能访问对象，他们不能做任何DDL操作，直到模式用户给你适当的特权。

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

在我小小的思想世界里:

我一直纠结于这样一个想法:我创建了N个用户，其中每个用户都“消费”(也就是使用)单个模式。

Tim在oracle-base.com上演示了如何做到这一点(有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.

这很简单。

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

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

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

我在某处读到，如果您的数据库用户拥有DDL特权，那么它就是一个模式，否则它就是一个用户。

基于我对甲骨文的一点了解…USER和SCHEMA有些相似。但也有一个主要的区别。如果“USER”拥有任何对象，则可以将其称为SCHEMA，否则…它将只保留为“USER”。一旦USER拥有至少一个对象，那么根据上面的所有定义....USER现在可以称为SCHEMA。

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

架构:关于数据库对象的信息集合。就像你书中的索引，它包含了关于该章节的简短信息。

详情请看这里

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

而模式是数据库对象的封装。这就像房子的主人拥有你房子里的所有东西，只有当主人(即模式)给它所需的授权时，用户帐户才能访问家里的商品。

——USER和SCHEMA

用户和模式这两个词是可以互换的，这就是为什么大多数人对下面这个词感到困惑的原因

——User“User”是连接数据库(Server)的帐号。我们可以使用create user user_name IDENTIFIED by password来创建用户。

——模式

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

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

我们可以使用Drop schema schama_name RESTRICT语句删除模式，但它不能删除模式中包含的对象，因此要删除模式，它必须为空。这里的限制词强制指定没有对象的模式。

如果我们试图删除一个用户包含对象，我们必须指定CASCADE字，因为oracle不允许你删除用户包含对象。 DROP用户user_name级联 因此oracle会删除模式中的对象，然后自动删除用户，从其他模式(如视图和私有同义词)中引用该模式的对象将进入无效状态。

我希望你现在已经明白了它们之间的区别，如果你对这个话题有任何疑问，请尽管问。

谢谢你！

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

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