Difference between SQL Server and Oracle 'User' - sql-server

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.

Related

How user, database and schema are related in Teradata?

I am aware of Oracle. In oracle schema or user is more or less same. When we create a user, schema is created.
Database is something we create when we install oracle.
I am new to Teradata. Are things same in case of Teradata too?
How user, database and schema are related in Teradata?
The full Teradata system is quite similar to a database in Oracle.
A database in Teradata is the same as a schema in Oracle.
A user is almost the same as a database in Teradata ( you can create objects in both), the main difference is the ability to logon to the system.
And there's a hierarchy of users & databases in Teradata, root is user dbc. Users might own databases and databases might own users. A user has the implicit right to manage his children (i.e. GRANT & REVOKE access rights on owned databases & users).
End users are usually a leaf in the hierarchy, no children & no perm space to store tables.
For more details see: About Databases and Users in Teradata

what is the significance of schema name in SQL server

I am new to SQL Server. I connected to SQL server via SQuirrel Client.
Connection URL:
jdbc:sqlserver://192.xx.xx.xx:1433;databaseName=ep
with username & password.
Then I tried a query on table1 in schema1 -
SELECT * from table1
It returned records. I did not mention schema name in query.
There may be possibility of having tables in different sachems (same database) with same name.
Am I right? If yes, then how will it resolve schema name?
Schema work like a namespace in SQL SERVER, you can create tables, views, sps under a schema and set GRANT, DENY, or REVOKE permissions on those objects. From Implementation of Database Object Schemas
SQL Server 2005 implemented the concept of a database object schema. A schema is a distinct namespace to facilitate the separation, management, and ownership of database objects. It removed the tight coupling of database objects and owners to improve the security administration of database objects. Database object schemas offer functionality to control and help secure application objects within a database environment not available in previous versions of SQL Server.
Just wanted to add here, if you have not specified any schema than, it select dbo as schema.
It is distinguished by its owner. Every object (table ,view ,proc) has an owner which must be a user in the database. For example you may have user1.table1 and user2.table2 in the same database.
So you may type
select * from user1.table1
and
select * from user2.table1
You may see names like dbo.table_name, this means that the owner is the dbo, the database owner. If you do not specify an owner then the system checks dbo and your user (the user that run the command)

Regarding the purpose of database schema

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.

Oracle database: Group tables in folders, like Postgres Schemas?

is there a way to group tables into Postgres's schema like structure? We have a Postgresql server we want to move to Oracle DB. We use a lot of schemas to categorize tables. Anything Similar in oracle? Oracle has Schemas but there is a one to one relation between schema and a user. Schema == User.
Is there another stack-exchange that might be more appropriate for this question?
You will need to create the same amount of schemas in Oracle as you did in PostgreSQL. The fact that each schema is also associated with a user should not bother you.
You don't have to log-in with all those users if that's what you are wondering.
Just create one "application" user, and grant the necessary privileges on the tables you create in the various schemas to that application user.
If you used PostgreSQL's search path feature to avoid fully qualified table names, then you'll need to create synonyms (owned by the "applicatoin" user) that point to the tables in the various schemas.

SQL Server roles, schemas, users

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

Resources