This question already has answers here:
SQL dot notation
(3 answers)
Closed 8 months ago.
I don't understand what's the difference between table name / schema name? Because I have connected to AdventureWorks database and then I wrote this query. So in this does this HR.Employee mean a table or something else?
select * from HR.Employee
I think the question is valid and far from trivial. Here's a big picture perspective.
In general, a database object is identified by a 4 part name. The "servername" is really an instance name. Brackets are optional if the naming follows the rules for naming identifiers. If a named instance, brackets are required because "\" is not legal. A default instance using a FQDN for the machine also needs brackets because of the periods. You don't have to specify all the parts if the defaults are okay; however, it is a best practice to at least specify the schema_name even if it is dbo. I added a links re the 4 part name, identifiers, and ownership chaining.
[server_name].[database_name].[schema_name].[object_name]
https://learn.microsoft.com/en-us/sql/t-sql/language-elements/transact-sql-syntax-conventions-transact-sql?view=sql-server-ver16
https://learn.microsoft.com/en-us/sql/relational-databases/databases/database-identifiers?view=sql-server-ver16
https://learn.microsoft.com/en-us/sql/relational-https://learn.microsoft.com/en-us/previous-versions/sql/sql-server-2008-r2/ms188676(v=sql.105)?redirectedfrom=MSDN
To simplify, think of a "servername" as an instance that contains databases. Access is controlled via server logins and login mappings to database users.
The database has objects to store and manipulate data. The security to access any objects in the database is defined in the database. A 4 part name used in a database can be used to access an object in a database on a different instance. A 3 part name can be used to access a object in a different database on the same server. In either case, a distributed transaction is used. (We have code that does this and it's a nightmare to support. Joining tables from different databases on different servers or the same server each has it's support problems.)
Now for schema_name. Suppose you have two related businesses that share a large amount of data and workflow but require guaranteed isolation of some data. A contrived example: a court application that stores data for both the DA and the public defender. They don't trust each other, but lets say they agree to not use separate servers and separate databases because they trust IT to isolate and protect their data. And IT is more than happy to avoid the need to code the application to use 2 databases which might avoid extra work (e.g., replication, distributed transactions, BizTalk, Mulesoft,...). A developer might rather use linked servers and distributed queries to move the complexity from development to support. Instead, we can use one database with a "DA" schema for DA tables and procedures while using a "PD" schema for public defender tables and code. Access to each schema can be controlled.
If everything was in the default "dbo" schema, any "dbo" procedure would have access to all "dbo" tables because of ownership chaining. Ownership chaining does not apply across schemas. The DA coder might reference a PD table or procedure in a DA procedure, but they won't have access to PD unless it's specifically granted. The schema allows isolation of groups of objects from each other and adds a layer of security to control access from one schema to another. If you use schemas thinking it's just a container to organize objects, it becomes quickly painful because of the lack of ownership chaining. As with most things SQL, it depends. This avoids pain if this is what you need to meet security requirements.
If you want a really short answer, the HR schema exists to secure HR data from unauthorized access by code in other schemas.
Related
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 using .net mvc and sqlserver db.
EDIT
We are also using NHibernate for data access. I mention this because we will not be writing our own sql or do stored procs. triggers in the db might work but I don't know if you can do that between databases.
END EDIT
we want to have a multi tenant set up so each client has there own instance of the db. However, we need to have each tenant connect to an other database which has a great deal of user information. there will be some small amount of shared data between them. Basically the tenants will be referencing the data of the users in the shared database.
The idea is that some people will use just the shared database ( independent clients ) they then may well be hired by one of the tenant clients. the tenant will then want access to the new employees data in the shared database. Further the employee may leave one tenant and join another or leave one and remain independent and want access to thier data. We could of course have the shared database schema in each tenant and just do a big export import each time some one left or joined but this seems like a lot of trouble too.
I am asking for any advice on how to manage the fact that the tenants will have references to the shared database but no referential integrity. Or if there is an alternate approach or whatever.
Thank you,
Raif
Across databases you have to give up declarative referential integrity (foreign keys). However you can still enforce this (if you think you need to) using after or instead of triggers, or if you control all data manipulation via stored procedures, you can do it there (on insert or update, for example, you can check first, or as part of the modification join to or use EXISTS against the table(s) in other databases to be sure that a valid value is being used).
I've worked with multi-tenant models and there can be huge benefits that are worth the costs (e.g. giving up DRI in some cases). For things that are mostly reference data and that aren't free-text entry, there shouldn't be a whole lot of extra effort required.
Consider a database server whose job today is to house one database. Likely the database will be moved in the future to another database instance which houses multiple databases & schemas.
Let's pretend the app/project is called Invoicer 2.0. The database is called AcmeInvoice. The database holds all the invoice, customer, and product information. Here's a diagram of the actors and their roles and behaviour.
The schema(s) will largely be used to easily assign permissions to roles. The added benefit here is that the objects aren't under dbo, and that the objects & permissions can be ported to another machine in the future.
Question
What conventions do you use when naming the schema?
Is it good form to name the schema the same as the database?
I would think that if your schema name ends up being the same as your database schema, then you are just adding redundancy to your database. Find objects in your database that have common scope or purpose and create a schema to relect that scope. So for example if you have an entity for Invoices, and you have some supporting lookup tables for invoice states, etc, then put them all in an invoice schema.
As a generally rule of thumb, I would try to avoid using a name that reflects the application name, database name or other concrete/physical things because they can change, and find a name that conceptually represents the scope of your objects that will go into the schema.
Your comment states that "the schemas will largely be used to easily assign permissions to roles". Your diagram shows specific user types having access to some/all tables or some/all stored procs. I think trying to organize objects conceptually into schemas and organize them from a security standpoint into schemas are conflicting things. I am in favour of creating roles in sql server to reflect the types of users, and grant those roles access to the specific objects that each user type needs, as apposed to granting the role or user access the schema to build your security framework..
Why would you name the schema the same as the database? This means all database objects fall under the same schema. If this is the case, why have a schema at all?
Typically schema's are used to group objects within a common scope of activity or function. For example, given what you've described, you might have an Invoice schema, a Customer schema and a Product schema. All Invoice related objects would go into the Invoice schema, all Customer related objects would go into the Customer schema, and the same for Products.
We often will use a Common schema as well which includes objects that might be common to our entire application.
I would call the database AcmeInvoice (or another suitable name) and the schema Invoicer2.
My reasons are as follows: Acmeinvoice means I am grouping all of that applications objects/data together. It can therefore be moved as one unit to other machines (a backup/restore or unattach/attach).
The schema would be Invoicer2. Applications change, maybe in the future you will have Invoicer21 (you would create a schema), or perhaps a reporting module or system (Reports schema).
I find that the use of schemas allows me to separate data/procedures in one database into different groups which make it easier to adminster permissions.
what is the difference between creating ordinary tables using 'dbo' and creating tables using schemas.How this schema works & supports the tables
A schema is just a container for DB objects - tables, views etc. It allows you to structure a very large database solution you might have. As a sample, have a look at the newer AdventureWorks sample databases - they have a number of schemata included, like "HumanResources" and so forth.
A schema can be a security boundary, e.g. you can give or deny certain users access to a schema as a whole. A schema can also be used to keep tables with the same name apart, e.g. you could create a "user schema" for each user of your application, and have a "Settings" table in each of them, holding that user's settings, e.g. "Bob.Settings", "Mary.Settings" etc.
In my experience, schemata are not used very often in SQL Server. It's a way to organize your database objects into containers, but unless you have a huge amount of database objects, it's probably something you won't really use much.
dbo is a schema.
See if this helps.
Schema seems to be a way of categorizing objects (tables/stored procs/views etc).
Think of it as a bucket to organize related objects based on functionality.
I am not sure, how logged in SQL user is tied to a specific schema though.
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