Login or Sign Up to become a member!
LessThanDot Sit Logo

LessThanDot

Data Management

Less Than Dot is a community of passionate IT professionals and enthusiasts dedicated to sharing technical knowledge, experience, and assistance. Inside you will find reference materials, interesting technical discussions, and expert tips and commentary. Once you register for an account you will have immediate access to the forums and all past articles and commentaries.

LTD Social Sitings

Lessthandot twitter Lessthandot Linkedin Lessthandot friendfeed Lessthandot facebook Lessthandot rss

Note: Watch for social icons on posts by your favorite authors to follow their postings on these and other social sites.

Your profile

    Search

    XML Feeds

    Google Ads

    « SQL Server DBA Tip 8 - Server Monitoring - BaselineCompressing Data with Uniqueidentifier columns »
    comments

    It was a dark and stormy night.  Database User Fred had an idea to venture into tables he wasn’t supposed to be in…OK, really that was for my buddy Noel McKinney (Twitter | Blog).  At some point when you are writing, the single largest barrier is the first line.  Thanks to Noel, I have my first line and we can get to it…

    Prior to SQL Server 2005, Schemas were not much more than a form of a database user.  Schemas since the SQL Server 2005 release are now a form of containment in which grouping of objects can be performed.   This is beneficial to security because we can create inner secured groupings of objects in a single database and quickly move objects contained in that group to other areas.  The value in this for a DBA is seen in controlling their own work.  Best practice tells us we should create a user database that we use for maintenance and other administrative tasks on SQL Server.  These databases can quickly become littered with tables and their exact purposes hard to manage.  Using Schemas, DBAs can group the tables into meaningful groups, such as index tables in an IndexMaint schema and DMV collections into a Baseline schema.  Once this is set up, the tables are identified quickly by the schema they are contained in.

    Create a basic Schema

    Create a basic Schema by using the CREATE SCHEMA statement.

    1. CREATE SCHEMA FinanceTables
    2. GO

    The FinanceTables Schema will contain all tables that are related to financials for the database ERP.  The database instance has a user login Fred and this login is mapped to a database user in the database ERP.  To restrict Fred to the FinanceTables, the ALTER AUTHORIZATION statement is used.  Once Fred is authorized to alter the schema FinanceTables, Fred can create tables.

    1. ALTER AUTHORIZATION ON SCHEMA::FinanceTables TO Fred
    2. GO
    3. GRANT CREATE TABLE to Fred
    4. GO

    Fred is now allowed to create tables in the schema FinanceTables but not allowed to create tables in any other schemas.  To test this, run the following statement to create a table in the schema dbo.

    1. CREATE TABLE dbo.Sales (MyMula Money)
    2. GO

    Resulting error message:

    Msg 2760, Level 16, State 1, Line 1
    The specified schema name "dbo" either does not exist or you do not have permission to use it.

    schema to FinanceTables and attempt to run the statement again.

    1. CREATE TABLE FinanceTables.Sales (MyMula Money)
    2. GO

    The Sales table is created successfully under the schema FinanceTables, and Fred is in control of it.  The value in this is containing the tables Fred creates and accesses to the entity FinanceTables as well as preventing Fred from creating tables in any other schemas in the database. 

    Moving objects from schema to schema

    DBAs can benefit from schemas by having the ability to quickly move from one schema to another schema.  This is accomplished by using the ALTER SCHEMA statement.

    1. ALTER SCHEMA IndexMaint TRANSFER dba.indexlog;
    2. GO

    This change does not truly move the table but redefines the schema that owns it.  This method can be used to change security on a wide range of objects quickly.  Moving the entire contents can be performed as shown in the Wiki entry, “Move all tables from one schema to another quickly

    Resources

    CREATE SCHEMA

    ALTER SCHEMA

    ALTER AUTHORIZATION

    About the Author

    Ted Krueger is a SQL Server MVP and has been working in development and database administration for 13+ years. Specialties range from High Availability and Disaster / Recovery setup and testing methods down to custom assembly development for SQL Server Reporting Services. Ted blogs and is also one of the founders of LessThanDot.com technology community. Some of the articles focused on are Backup / Recovery, Security, SSIS and working on SQL Server and using all of the SQL Server features available to create stable and scalable database services. @onpnt
    Social SitingsTwitterLinkedInLTD RSS Feed
    748 views
    Instapaper

    1 comment

    Comment from: David Forck (thirster42) [Member]
    yes, schemas are awesome. i use them to break out security and define purposes for things.

    in a typical database i'll having a generic schema for the database, an sp for sp's that aren't meant for users, staging for any sort of etl processes, and rs if i'm working on reports.
    05/04/11 @ 09:53

    Leave a comment


    Your email address will not be revealed on this site.

    Your URL will be displayed.
    (Line breaks become <br />)
    (Name, email & website)
    (Allow users to contact you through a message form (your email will not be revealed.)