Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 


 
     
Recent Posts
   
Popular Topics
Home   
Search
    Members    Calendar    Who's On

Home » SQL Server 2008 » SQL Server Newbies » supplying a schema in queries, performance?
Add to briefcase
15 posts, Page 1 of 2
12»»

supplying a schema in queries, performance? Expand / Collapse
Rate Topic
Display Mode
Topic Options
Author
Message
BinaryDigit
Posted Tuesday, March 12, 2013 7:51 AM


SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Today @ 3:03 AM
Points: 89, Visits: 190
Hi

A random question, if you write queries and put the schema before objects will it affect performance in any way and if so what type of metrics are we looking at? even if they are tiny

Regards
Gordon Beeming



The Fastest Methods aren't always the Quickest Methods
Post #1429821
ryan.mcatee
Posted Tuesday, March 12, 2013 12:19 PM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Yesterday @ 9:35 AM
Points: 43, Visits: 119
I have a SQL server instructor (Bell) who told me it does require some CPU cycles to resolve a name if it is not qualified with a schema name. Also, if you do NOT qualify the schema, what schema will be used? (I think, by default, the schema that contains the stored procedure will be the default schema rather than the default schema of the current user or the default schema of the database).

For these reasons, as a general practice, I always qualify database objects in stored procedures as two-part names.
Post #1430043
ryan.mcatee
Posted Tuesday, March 12, 2013 12:24 PM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Yesterday @ 9:35 AM
Points: 43, Visits: 119
To clarify, say we have three tables:

schemaA.MyTable
schemaB.MyTable
dbo.MyTable


If my current-logged in user's default schema is schemaA and the default schema for the database is schemaB. And we create a stored procedure named dbo.SomeStoredProcedure that does this:

SELECT * FROM MyTable


It will actually query from dbo.MyTable, not schemaA.MyTable or schemaB.MyTable.


If someone could explain this behavior, I would appreciate it.
Post #1430046
Ed Wagner
Posted Tuesday, March 12, 2013 12:39 PM
SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Thursday, May 16, 2013 6:44 AM
Points: 1,856, Visits: 528
Every user in a database has a default schema whether they like it or not. This is at the database user level, not the login level. If you don't specify a schema in your query, you'll be querying the table in your default schema. As far as I know, if you don't specify a schema, it won't look in any other schema for the table you query.
Post #1430053
Lowell
Posted Tuesday, March 12, 2013 12:40 PM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Today @ 3:06 PM
Points: 11,638, Visits: 27,712
ryan.mcatee (3/12/2013)
To clarify, say we have three tables:

schemaA.MyTable
schemaB.MyTable
dbo.MyTable
If my current-logged in user's default schema is schemaA and the default schema for the database is schemaB. And we create a stored procedure named dbo.SomeStoredProcedure that does this:
SELECT * FROM MyTable
It will actually query from dbo.MyTable, not schemaA.MyTable or schemaB.MyTable.
If someone could explain this behavior, I would appreciate it.


for objects not qualified with the schema name,SQL Server looks for the object in the default schema your user belongs to first, then in dbo schema. if my default schema is SchemaC, SchemaA and SchemaB are not even checked to see if the object exists... only SchemaC then

In your procedure, you would simply see that behaviour being applied: objects not qualified with the schema name will assume dbo, which is the schema of the containing object and if it doesn't exist, would fail with object not found.

edit: corrected because my assumptions were way way wrong! Thanks Lynn Pettis!

Lowell

--There is no spoon, and there's no default ORDER BY in sql server either.
Actually, Common Sense is so rare, it should be considered a Superpower. --my son
Post #1430055
Ed Wagner
Posted Tuesday, March 12, 2013 12:46 PM
SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Thursday, May 16, 2013 6:44 AM
Points: 1,856, Visits: 528
The dbo schema first, then default. Thank you, Lowell. I just learned something.
Post #1430057
Lynn Pettis
Posted Tuesday, March 12, 2013 2:30 PM


SSC-Insane

SSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-Insane

Group: General Forum Members
Last Login: Today @ 4:34 PM
Points: 21,615, Visits: 27,445
Ed Wagner (3/12/2013)
The dbo schema first, then default. Thank you, Lowell. I just learned something.


Actually, if you do not provide the schema for the object it will look first in the users default schema, then it will look in the dbo schema.

I just tested this myself.


Lynn Pettis

For better assistance in answering your questions, click here
For tips to get better help with Performance Problems, click here
For Running Totals and its variations, click here or when working with partitioned tables
For more about Tally Tables, click here
For more about Cross Tabs and Pivots, click here and here
Managing Transaction Logs

SQL Musings from the Desert Fountain Valley SQL (My Mirror Blog)
Post #1430096
ryan.mcatee
Posted Tuesday, March 12, 2013 2:33 PM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Yesterday @ 9:35 AM
Points: 43, Visits: 119
The behavior is different within a stored procedure.
Post #1430101
Lynn Pettis
Posted Tuesday, March 12, 2013 2:38 PM


SSC-Insane

SSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-Insane

Group: General Forum Members
Last Login: Today @ 4:34 PM
Points: 21,615, Visits: 27,445
ryan.mcatee (3/12/2013)
The behavior is different within a stored procedure.


Will have to research further later.
It is interesting behaviour.


Lynn Pettis

For better assistance in answering your questions, click here
For tips to get better help with Performance Problems, click here
For Running Totals and its variations, click here or when working with partitioned tables
For more about Tally Tables, click here
For more about Cross Tabs and Pivots, click here and here
Managing Transaction Logs

SQL Musings from the Desert Fountain Valley SQL (My Mirror Blog)
Post #1430103
Lynn Pettis
Posted Tuesday, March 12, 2013 2:40 PM


SSC-Insane

SSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-Insane

Group: General Forum Members
Last Login: Today @ 4:34 PM
Points: 21,615, Visits: 27,445
Lynn Pettis (3/12/2013)
ryan.mcatee (3/12/2013)
The behavior is different within a stored procedure.


Will have to research further later.
It is interesting behaviour.


Especially when you deal with ownership chaining.


Lynn Pettis

For better assistance in answering your questions, click here
For tips to get better help with Performance Problems, click here
For Running Totals and its variations, click here or when working with partitioned tables
For more about Tally Tables, click here
For more about Cross Tabs and Pivots, click here and here
Managing Transaction Logs

SQL Musings from the Desert Fountain Valley SQL (My Mirror Blog)
Post #1430105
« Prev Topic | Next Topic »

Add to briefcase
15 posts, Page 1 of 2
12»»

Permissions Expand / Collapse

 
 
Copyright © 2002-2013 Simple Talk Publishing. All Rights Reserved. Privacy Policy. Terms of Use. Report Abuse.