A server can create multiple instances, each instance can be placed in the database (Note: our computer can be called a server)
A database in Oracle is an instance, but there can be multiple databases under an instance in sqlserver
(Note: multiple databases corresponding to an instance in sqlserver are also called libraries here.)
1. In Oracle, the table belongs to the user, and the progressive relationship is: instance (database) -> user -> table. The
table belongs to a certain user. If other users (except the administrator) want to access the table, they must get the The user's authorization can access this table,
so if a user wants to create a table, he must first have permission to use the database table space to set the table space for the user to store the created table.
In this way, the steps to connect to the database can be explained. First, the administrator creates a user in the database, but at this time the user is still unable to connect, so first give him permission to connect.
It is connected, and no table space is allocated to it, and then the authorization to use the table space is given to him, so that the user can create tables normally and use additions, deletions, and modifications.
But it is different in sqlserver. The tables belong to the database. The database creates the tables. The progressive relationship is: instance -> (multiple) databases -> tables, which
can be understood as the user's database and table Is independent. Therefore, in sqlserver, it is generally to build a database, build a table, build a user, and then set which permissions the user can use.
2. In Oracle, there is a one-to-one correspondence between a scheme and a user, but it does not mean that creating a user is equivalent to creating a scheme. The scheme only
occurs after the user creates the first object . After that, if there is an object under the user, the plan exists, and if there is no object under the user, the plan does not exist.
注：举个例子
SQL> Grant dba to scott
SQL> conn scott/tiger
Connected.
SQL> create table test(name char(10));
Table created.
SQL> create table system.test(name char(10));
Table created.
SQL> insert into test values(‘scott’);
1 row created.
SQL> insert into system.test values(‘system’);
1 row created.
SQL> commit;
Commit complete.
SQL> conn system/manager
Connected.
SQL> select * from test;
NAME
system
SQL> ALTER SESSION SET CURRENT_SCHEMA = scott; --Change the user's default schema name Session altered.
SQL> select * from test;
NAME
scott
SQL> select owner ,table_name from dba_tables where table_name=upper(‘test’);
OWNER TABLE_NAME
SCOTT TEST
SYSTEM TEST
This proves that after the user created the first object, the scheme was generated later. The name of the default scheme is the same as the name of the user,
but the user can change the default scheme pointed to. Here the system user finally points to scott The plan, that is, a plan is pointed to by two users.
(Note: The system user modified the scheme here. It does not mean that the original one can no longer be accessed. The two can be accessed, but the system will set the path of the default scheme for the user, that is, when accessing the object, If you don’t add the name of the scheme before, the objects in the default scheme are used. If you add other names, you can access the objects in other schemes, provided that the owner of the other schemes will give you the authority of the objects in it. And you can’t give permission to the scheme, because it’s a logical concept
and it’s not defined in the database. Instead, it needs to be delivered with the authority of one object per object) -> The user can access one or more schemes, depending on the original owner of the scheme Did you give him the permissions of the objects in the plan? A program can also be accessed by multiple users.
But because there is still an object in the original system scheme, it will not disappear, it will still exist. Moreover, system users still have access to the system scheme, so they can still continue to access. The user scheme changed here is actually the default scheme.
(Note: The database in Oracle is actually a collection of schemes, because a scheme is a collection of objects. Although there is no real definition scheme in the database, it is just a logical concept)
Quote:
The following is a very vivid analogy, which is taken from the Internet. Let’s take a look: We can think of a database as a large warehouse. The warehouse is divided into many, many rooms. The schema is one of the rooms, and a schema represents a room. A table can be regarded as a bed in each schema. The table is placed in each room and cannot be placed outside the room. Wouldn't it be that you are homeless when you sleep at night, and then you can put a lot of items on the bed, just like a table Many columns and rows can be placed on the database. The basic unit of data storage in the database is the table. The basic unit of items placed in each warehouse in the display is the bed. The user is the owner of each schema (so the schema contains object, not user), user and schema have a one-to-one correspondence. Each user can only use its own schema without special designation. If a user wants to use other schemas, it depends on which schema user has given you. This permission, or see if the boss (DBA) of this warehouse has given you this permission. In other words, if you are the owner of a certain warehouse, then the right to use this warehouse and everything in the warehouse are yours. You have full operation right, you can throw away unnecessary things from every room, and you can also prevent For some useful things to a certain room, you can also assign specific permissions to each user, that is, what can he do in a certain room, is it read-only, or can he have everything like the owner? Control (R/W), this depends on the role the user corresponds to.
