Doing my databases reading when I read...
Schema: Is a container for objects
Tablespace: A logical storage unit for objects
Can anyone explain the difference between these?
A schema is a namespace - a logical thing. It is used to organize the names of database objects. It has nothing to do with the way the data is stored.
A tablespace is a physical thing. It's a container for data and has nothing to do with the logical organization of the database objects.
A single object (e.g. a table) could be spread across multiple tablespaces (depending on the DBMS being used) but it can only be defined in a single schema. The table schema_1.table_1 is a different table than schema_2.table_1 - although the "plain" name is the same, the fully qualified name is different and therefore those are two different tables.
Objects that are organized in the same schema are not necessarily stored in the same tablespace. And a single tablespace can contain objects from different schemas.
Schemas (and catalogs, which are another level of namespace) are part of the SQL language and are defined in the SQL standard.
Tablespaces are part of the physical storage and are DBMS-specific (although nearly all DBMS support a concept like that) and are not part of the SQL query language (as defined by the SQL standard). They are, however, defined and managed through vendor-specific SQL/DDL statements.
Schema operates the logical structures.
While Tablespaces operate physical datafiles that constitute the database.
From Oracle documentation:
Schema:
A schema is a collection of database objects. A schema is owned by
a database user and has the same name as that user. Schema objects
are the logical structures that directly refer to the database's data.
Schema objects include structures like tables, views, and
indexes. (There is no relationship between a tablespace and a schema. Objects in the same schema can be in different tablespaces,
and a tablespace can hold objects from different schemas.)
Tablespaces:
A database is divided into one or more logical storage units called
tablespaces. Tablespaces are divided into logical units of storage
called segments, which are further divided into extents. Extents are a
collection of contiguous blocks.
The size of a tablespace is the size of the datafiles that constitute the tablespace. The size of a database is the collective size of the tablespaces that constitute the database.
You can enlarge a database in three ways:
Add a datafile to a tablespace
Add a new tablespace
Increase the size of a datafile
There is no relationship between schemas and tablespaces: a tablespace can contain objects from different schemas, and the objects for a schema can be contained in different tablespaces.
FROM ORACLE DOCUMENTATION.
https://docs.oracle.com/cd/B10500_01/server.920/a96524/c11schem.htm
Related
In Snowflake Which of the following objects can be cloned?
A. Tables
B. Named File Formats
C. Schemas
D. Shares
E. Databases
F. Users
Tables, Schemas and Databases I know but can we also clone Users or Named File Format?
You can directly clone DATABASE, SCHEMA, TABLE, STREAM, STAGE, FILE FORMAT, SEQUENCE, and TASK objects:
https://docs.snowflake.com/en/sql-reference/sql/create-clone.html#syntax
In Snowflake, the following objects can be cloned:
Data Containment Objects
Databases
Schemas
Tables
Streams
Data Configuration and Transformation Objects
Stages (external only - not internal)
File Formats
Sequences
Tasks
The following account level objects cannot be cloned:
Users
Roles
Grants
Virtual Warehouses
Resource monitors
Storage integrations
From Database System Concepts, by Silberschatz et al:
4.5.7 Schemas, Catalogs, and Environments
Like early file systems, early database systems also had a single name
space for all relations. Users had to coordinate to make sure they did
not try to use the same name for different relations. Contemporary
database systems provide a three-level hierarchy for naming relations.
The top level of the hierarchy consists of catalogs, each of which can
contain schemas. SQL objects such as relations and views are contained
within a schema. (Some database implementations use the term
“database" in place of the term catalog.)
In order to perform any actions on a database, a user (or a program)
must first connect to the database. The user must provide the user name
and usually, a password for verifying the identity of the user. Each
user has a default catalog and schema, and the combination is unique
to the user. When a user connects to a database system, the default
catalog and schema are set up for the connection; this corresponds to
the current directory being set to the user’s home directory when the
user logs into an operating system.
To identify a relation uniquely, a three-part name may be used, for
example, catalog5.univ schema.course We may omit the catalog
component, in which case the catalog part of the name is considered to
be the default catalog for the connection. Thus if catalog5 is the
default catalog, we can use univ schema.course to identify the same
relation uniquely.
A relation has a schema, which is the collection of all the
attributes of the relation. The "schema" in the above quote seems
to correspond to more than one relations. Does "schema" in the
above quote mean the same as the schema of a relation?
What is the relation between catalogs and databases? Is the relation
between catalogs and databases one-to-one?
What do the catalogs and schemas look like in mysql, postgresql, or
SQL Server?
Thanks.
Your first sentence in # 1 makes no sense.
A table/relation like “person” has attributes/columns like “name”, “phone”, and “email”.
Tables are grouped together in a namespace known as a schema. So a schema such as “warehouse” can have a table named “person” while another schema such as “sales” can also have a table coincidentally named “person”. Each catalog has one or more schema, each schema carrying a name such as “warehouse” and “sales” seen here.
A schema commonly acts a security boundary, besides being a namespace. As far as I know, that is an implementation detail, not required by the SQL standard.
The word “schema” is also commonly used in a different, more casual and general way, to describe the tables & columns design choices made to fit the needs of an application. See first comment by IMSoP below. A schema in the casual sense might involve any number of catalogs, schemas, tables, and columns in the formal SQL Standard sense.
As for # 2, your quotation explains that. “Catalog” and “database” are synonyms. The word “catalog” is used formally by the SQL standard.
For # 3, advanced databases striving to implement the SQL standard typically support all levels defined by the standard: cluster > catalog > schema > table. This includes both Postgres and Microsoft SQL Server.
H2 Database Engine supports separate databases, each being a catalog with schemas, but no cluster grouping the catalogs/databases together.
MySQL is more limited and does not support the full hierarchy, from what I can tell in my limited searching of MySQL documentation.
For more info, see this related Question: What's the difference between a catalog and a schema in a relational database?
I am creating a database with about 40 different tables.
I have heard about people grouping tables into database 'schemas' - what are the implications of using different schemas in a database? Can tables from one schema still relate to another schema? What are the functional differences between different schemas?
Where are schemas located in SSMS? They are rightfully placed under the security tab.
Lets use the AdventureWorks databases.
If you assign security at the schema level, purchasing users will only have access to the purchasing table and sales people will have only access to the sales tables.
In fact, they will not even see the other tables if you set it up correctly.
If you combine schemas with creating tables/indexes on file groups, now you can place all the sales people onto file group sales and purchasing on file group purchasing.
IE - Spreading the I/O load.
In short, I think schemas are an unknown and little used feature.
Check out my blog article on this fact.
http://craftydba.com/?p=4326
I assume that you are talking about SQL Server. You can join and reference between tables in different schemas. I see it mostly used for visual organization and/or for managing objects' permission (you can assign permissions at the schema-level).
If you are worried about any negative effects of doing dbo.table vs custom.table - there aren't any that I imagine you would encounter.
Schemas are just collections of database objects. They are useful for maintaining separation of sets of objects.
There is always at least one schema. For SQL Server it is named dbo.
One implication of having multiple schemas is that you will have to manage permissions for the various schemas. This is usually done via a role that's associated with the schema.
Objects in one schema are available to objects from another, and there is no performance penalty in writing queries that use objects from multiple schemas.
we are working on data migration of sql server 2000 to Oracle 11g. Sql server has 4 databases which has to be migrated. These 4 databases are used for 6 different standalone applications. Oracle is installed in Unix server. Can we create a single database and different schemas for each sql server database or do I need to create multiple databases or can I use single database, single schema and multiple tablespaces or any other procedure to maintain the performance?
You can create multiple Oracle databases. Or you can create a single database with multiple schemas. Or you can create a single database with a single schema an put everything there if all your object names are unique.
The most similar approach would generally be to create a single Oracle database with four schemas. That gives you four separate namespaces in case you have objects in two different SQL Server databases that have the same name. And a single Oracle database per server generally gives the best performance since you're not allocating multiple SGAs and PGAs in memory or running multiple sets of background processes.
Tablespaces in Oracle are a completely separate concept. They have nothing to do with namespaces or permissions. They simply allow you to determine which objects reside in which physical data files. Barring something extremely unusual, tablespaces have nothing to do with performance. You could have the objects in all four schemas use a single tablespace. Or you could create four separate tablespaces. Or you could create multiple tablespaces that each have objects from different schemas. My guess is that the simplest approach is to create one tablespace per schema so that you can manage each application's disk space allocation separately.
What is the importance of schema in sql server?
Where this schema help me?
Is it important for security reasons?
Yes, the primary purpose of SQL schema was -is- to facilitate security management: define who [which principals] can access what [which database objects]. This was made particularly easier starting with SQL 2005 when the schema stopped being directly tied to the owner.
Another use of schema is to serve as a namespace, that is preventing name clashes between objects from different schemas.
The original use of this was to allow multiple [interactive, i.e. ad-hoc like] users of a given database to create their own tables or stored procedures (or other objects), without having to worry about the existence of similarly named objects possibly introduced by other users.
The Namespace-like nature of schema can also be put to use in a planned database setting, i.e. one when a single architect designs the database structure in a way which provides distinct type of access, and indeed different behaviors, for distinct user groups.
They partition your database to make management easier.
This is from MSDN:
A schema is now a distinct namespace
that exists independently of the
database user who created it. In other
words, a schema is simply a container
of objects. A schema can be owned by
any user, and its ownership is
transferable.
Here's the page that came from: http://msdn.microsoft.com/en-us/library/ms190387.aspx
In relation to security it makes it simpler to assign permissions as you can grant someone access to a schema without exposing your entire database to them.
What a schema is changed with the release of SQL Server 2005 and later - I think of it as an additional security layer as well as a container of objects.
This is quite a good resource:
http://msdn.microsoft.com/en-us/library/ms190387(SQL.90).aspx
Schema is mainly used to Manage several logical entities in one physical database.
Schemas offer a convenient way to separate database users from database object owners. They give DBA’s the ability to protect sensitive objects in the database, and also to group logical entities together.
This is especially advantageous in situations where those objects are often utilized as a unit by applications. For example, a hotel-management system may be broken down into the following logical entities or modules: Rooms, Bar/Restaurant, and Kitchen Supplies.
These entities can be stored as three separate physical databases. Using schemas however, they can be combined as three logical entities in one physical database. This reduces the administrative complexity of managing three separate databases.
Source