a) I found two definitions of schema:
FIRST - A set of information that describes a table is known as a schema, and schemas are used to describe specific tables within a database, as well as entire databases (and the relationship between tables in them, if any).
SECOND - A database schema is a way to logically group objects such as tables, views, stored procedures etc. Think of a sche开发者_高级运维ma as a container of objects.
I assume the two descriptions describe entirely different concepts, which just happen to use the same name?
b)
A database schema is a way to logically group objects such as tables, views, stored procedures etc. Think of a schema as a container of objects.
If I understand the above definition correctly, then database schema is similar to a namespace, only difference being that we can assign access permissions to database schema, while same can’t be done with namespaces?
thanx
Yes, this can be confusing. Generally, in the context of relational databases in general, your schema is the collection of your database structures - your tables, views, keys, constraints, etc. Depending on whom you ask, this may or may not include triggers, user-defined functions, custom user types, stored procedures, and the like, but I lump them in as schema objects, as well.
Within the context of specific relational database management systems (e.g., MSSQL, Postgres), a schema is a logical grouping of database objects. It serves two purposes: 1) as you note, it acts as a namespace and allows you to group related database objects together, and reduces name collision; 2) you can assign security settings to the schema as a whole, rather than assigning permissions to the schema's objects individually.
The terminology collision is sometimes confusing, but intentional. It usually makes sense to talk about subsets of your entire schema, and to assign permissions and deal with behaviors on these subsets - and the database supports this by allowing you to group these subsets into their own schemas.
精彩评论