Please start any new threads on our new site at https://forums.sqlteam.com. We've got lots of great SQL Server experts to answer whatever question you can come up with.

 All Forums
 Old Forums
 CLOSED - General SQL Server
 Any reason not to use dbo. prefix?

Author  Topic 

timmy
Master Smack Fu Yak Hacker

1242 Posts

Posted - 2006-06-15 : 01:34:30
Hi all,

Is there any logical or technical reason why a DBA would not want to use dbo. prefix in stored procs/views/etc? I've heard of some DBA's requesting this, but I can't see any reason why. Perhaps someone here can elaborate on this?

Cheers,

Tim

jen
Master Smack Fu Yak Hacker

4110 Posts

Posted - 2006-06-15 : 01:40:21
they don't, some new breed of dba i guess, have you asked them why?

they are probably assuming that all objects are owned by dbo, if not then they'd want to know via error message or complaints coming from the dev?

--------------------
keeping it simple...
Go to Top of Page

Kristen
Test

22859 Posts

Posted - 2006-06-18 : 02:42:54
Only reason I can think of is if the same-named object can be owned by different people.

Each user could have a VIEW with a differently restricted WHERE clause, for example.

Other than that its going to cause a cache-miss on every query, which seems like a pretty bad idea to me!

Kristen
Go to Top of Page

cmdr_skywalker
Posting Yak Master

159 Posts

Posted - 2006-06-19 : 00:09:48
The prefixes (including dbo) provides organization and implementation of schema definiton of SQL92, FIPS Pub 127. A schema is a collection of named objects. In relational database technology, schemas provide a logical classification of objects in the database. Some of the objects that a schema may contain include tables, views, aliases, indexes, triggers, and structured types. To organize the data perspective, the user account is associated with the database schema.

Having a schema, it helps in the permission resolutions, metadata and database organization, and optimization to name just a few. See the web for more info on SCHEMA.
examples:
1. permission - not unless timmy explicitly grants access on diary table, noone will be able to read that table.
2. metadata and database organization - if user veteran deletes his production table, the production application still works because the application uses the table defined under the dbo (or anyother assigned production prefix) schema.
3. optimization - the prefix helps in identifying an existing cache and provides faster permission resolution.




May the Almighty God bless us all!
Go to Top of Page
   

- Advertisement -