I've been trying to figure out why SQL Server has db_owner schema and db_owner role? This is very confusing. I've been searching for answers and so far this is how my understanding goes:
All tables and objects (such as constraints etc) belong to a schema. DBO being the default schema.
A user may be given permission to edit each object or the schema. A permission on the schema extends the permission to all objects within that schema. So you don't have to grant permission on each individual object.
A role groups permissions together for convenience.
If any of this is incorrect let me know. But I think so far so good. Now my questions are:
What exactly is db_owner schema as seen in "Database User" dialog box of SQL Server Management Studio? And on the same dialog, you define the "Default Schema" as dbo. Why aren't the two the same? If by default SQL Server uses dbo to create all objects under, what use is db_owner?
Why would a user want to own a schema? You are assigning permissions/roles already. What does owning db_accessadmin give you?
Can you give an example of when you create objects under db_owner schema and db_accessadmin schema? In other words does anyone legitimately use those schemas?
A SQL Server schema is simply container of objects, such as tables, stored procedures, etc. A Database Role is a group of principals, such as windows logins, sql server users, etc.
The idea is you can have a role of say "IT", and have all IT users under that role. Then you have can a schema called "IT", and have all tables that belong to IT under that. Out of the box SQL Server creates matching schemas for each default user and role in the database, but I think the intention is you customize this to match the needs of your organization.
This article has more information on the differences between owners and schemas. This question on Stack Overflow may also be useful.
I am quoting the below from the following link.
https://msdn.microsoft.com/en-us/library/bb669061(v=vs.110).aspx
SQL Server ships with ten pre-defined schemas that have the same names as the built-in database users and roles. These exist mainly for backward compatibility. You can drop the schemas that have the same names as the fixed database roles if you do not need them. You cannot drop the following schemas:
dbo
guest
sys
INFORMATION_SCHEMA
Related
In SnowFlake, I want to provide access kind ofddl_admin in sql server to a user or role who can drop any tables in schema regardless anybody else is the owner of the table.
There is no concept of having a super role in Snowflake. Everything has to go by access hierarchy.
However, if all the roles are granted to ACCOUNTADMIN role then no matter which user creates the table, that can be dropped by ACCOUNTADMIN.
Using SQL Server 2014 Express. I'm new to SQL Server (more familiar with Oracle). I have a schema defined and a user defined as the schema owner. I cannot seem to find a way to allow the user to create tables inside the schema without granting db_owner role.
This will not work for my DB because there will be multiple schemas. With this database level role, ie db_owner, the user (schema owner) can create tables in any schema.
My goal is to have a schema owner user able to log into the DB and create tables and manage the schema and ONLY their own schema.
Can someone help me with this? I'm quite frustrated.
Thanks in advance.
After much research, I was able to figure out the answer to my own question:
"Create table" is only a database level permission, cannot be assigned at the schema level.
A user can be defined as the schema owner. If the user has "Create Table" permissions at the database level and is a schema owner, all tables will be created in the schema he/she owns.
A user cannot see other schemas unless granted "select" permission at the schema level by the schema owner (or someone with higher level authority). If the user has "Select" at the database level, he/she will see all schemas.
I read a write up about database schema.
A SQL Server schema is a container of objects. For example you may have a large enterprise application and then is a good practice to use different schemas for different purposes (e.g. put HR related tables into HR schema, accounting related tables into Accounting schema and so on). A schema can be owned by any user, and the ownership is transferable.
They said: use different schemas for different purposes (e.g. put HR related tables into HR schema, accounting related tables into Accounting schema and so on)
Do they mean create new database for HR and again new database for accounting?
Because when we create a database then a single schema is created so we cannot create multiple schema in single SQL Server database as far I know.
So please tell me how is it possible to create different schemas for different purposes in a single database? Thanks
Purpose of Schema
Schemas in sql server were introduced in sql server 2005, The main purpose was to eliminate User's ownership of objects in sql server. or you can say to separate users from objects in sql server.
Prior to Sql server 2005 objects in sql server (Tables, views, Store proceders etc) were owned by users. Typically the user who created it.
And that user had to give permissions to other users to use that particular object.
Imagine a scenario where 12 developers are working in a company and all developers are creating sql objects left, right centre. Now all the developers had to give permissions to other 11 developers if they had to work objects created by that one developer. quite a bit of mess isnt it??
Since sql server 2005 came with Schema. All the objects were Owned by a Schema Not a User. if you havent created any custom schema it will be under default Schema dbo.
Now anyone who has permission to dbo schema has permission to any object under dbo schema.
Why it is a good idea to create different schemas for different departments in your case. It may be because HR people doesnt need to know anything about Finance stuff. so you can create a HR schema and give HR people permission only on HR schema. and vice versa with finance people. That will restrict their access to only objects related to their departments.
And we can create multiple Schemas in one database if you have ever worked with Adventureworks database, it has Schemas like 'Production', 'Sales' etc etc.
Read here to learn more about schemas in sql server.
No they mean create a schema. Create schema works within a database. There are all sorts of uses for it, I tend to think of it as either namespacing or a more natural way of partitioning a smallish database and keeping role based access, where you can think of schema as a user group.
Unfortunately, there are two meanings to the word "schema" in the database world.
One means the overall design of the database tables. "Show me your database schema", for example. This would be the collection of "create table" commands, or and ERD diagram.
The other is a synonym for "namespace", which the article in question is referring to. You can store tables, functions etc in different namespaces to ease cognitive load or use for security grouping.
Are there any differences between a user in SQL Server and one in Oracle? If so, what are they?
In Oracle, the users and the schema are one thing. You can create two different tables with the same name, belonging to different users.
In SQL Server, schema and user are separate things. The users are only used to log in and define permissions.
See this question for more information: What is the difference between an Oracle and Microsoft schema?
Oracle schemas are like My Documents folders in the Windows OS. A user can grant permissions to other users to see things in their schema but an Oracle schema is essentially a user's workspace.
MS SQL Server's schemas are namespaces. While you can have Accounting and Marketing schemas, they are not tightly-coupled to individual users. Objects in an Accounting schema contain accounting information and objects in the Marketing schema have marketing information.
Oracle schemas are tightly-coupled to users and MS SQL Server schemas are primarily for classification.
At least on my local instance, when I create tables, they are all prefixed with "dbo.". Why is that?
dbo is the default schema in SQL Server. You can create your own schemas to allow you to better manage your object namespace.
If you are using Sql Server Management Studio, you can create your own schema by browsing to Databases - Your Database - Security - Schemas.
To create one using a script is as easy as (for example):
CREATE SCHEMA [EnterSchemaNameHere] AUTHORIZATION [dbo]
You can use them to logically group your tables, for example by creating a schema for "Financial" information and another for "Personal" data. Your tables would then display as:
Financial.BankAccounts
Financial.Transactions
Personal.Address
Rather than using the default schema of dbo.
It's new to SQL 2005 and offers a simplified way to group objects, especially for the purpose of securing the objects in that "group".
The following link offers a more in depth explanation as to what it is, why we would use it:
Understanding the Difference between Owners and Schemas in SQL Server
Microsoft introduced schema in version 2005. For those who didn’t know about schema, and those who didn’t care, objects were put into a default schema dbo.
dbo stands for DataBase Owner, but that’s not really important.
Think of a schema as you would a folder for files:
You don’t need to refer to the schema if the object is in the same or default schema
You can reference an object in a different schema by using the schema as a prefix, the way you can reference a file in a different folder.
You can’t have two objects with the same name in a single schema, but you can in different schema
Using schema can help you to organise a larger number of objects
Schema can also be assigned to particular users and roles, so you can control access to who can do what.
You can generally access any object from any schema. However, it is possible to control which users have which access to particular schema, so you can use schema in your security model.
Because dbo is the default, you normally don’t need to specify it within a single database:
SELECT * FROM customers;
SELECT * FROM dbo.customers;
mean the same thing.
I am inclined to disagree with the notion of always using the dbo. prefix, since the more you clutter your code with unnecessary detail, the harder it is to read and manage.
For the most part, you can ignore the schema. However, the schema will make itself apparent in the following situations:
If you view the tables in either the object navigator or in an external application, such as Microsoft Excel or Access, you will see the dbo. prefix. You can still ignore it.
If you reference a table in another database, you will need its full name in the form database.schema.table:
SELECT * FROM bookshop.dbo.customers;
For historical reasons, if you write a user defined scalar function, you will need to call it with the schema prefix:
CREATE FUNCTION tax(#amount DECIMAL(6,2) RETURNS DECIMAL(6,2) AS
BEGIN
RETURN #amount * 0.1;
END;
GO
SELECT total, dbo.tax(total) FROM pricelist;
This does not apply to other objects, such as table functions, procedures and views.
You can use schema to overcome naming conflicts. For example, if every user has a personal schema, they can create additional objects without having to fight with other users over the name.
Something from Microsoft (Documentation)
The dbo user is a special user principal in each database. All SQL Server administrators, members of the sysadmin fixed server role, sa login, and owners of the database, enter databases as the dbo user. The dbo user has all permissions in the database and cannot be limited or dropped. dbo stands for database owner, but the dbouser account is not the same as the db_owner fixed database role, and the db_owner fixed database role is not the same as the user account that is recorded as the owner of the database.
The dbo user owns the dbo schema. The dbo schema is the default schema for all users, unless some other schema is specified. The dbo schema cannot be dropped.
The dbo user owns the dbo schema. The dbo schema is the default schema for all users, unless some other schema is specified. The dbo schema cannot be dropped.
DBO is the default schema in SQL Server. You can create your own schemas to allow you to better manage your object namespace. As a best practice, I always add the "DBO." prefix even though it is not necessary. Most of the time in SQL it's good to be explicit.