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.
Author |
Topic |
X002548
Not Just a Number
15586 Posts |
|
robvolk
Most Valuable Yak
15732 Posts |
Posted - 2012-02-06 : 18:07:30
|
Yes, you've said it before. Yes, there are good, sound reasons for using them. Check your post history and you'll find some. |
 |
|
namman
Constraint Violating Yak Guru
285 Posts |
Posted - 2012-02-09 : 21:56:38
|
Are your serious xoo2548? |
 |
|
X002548
Not Just a Number
15586 Posts |
|
russell
Pyro-ma-ni-yak
5072 Posts |
Posted - 2012-02-10 : 15:53:30
|
There's multiple ways to do everything. Your reluctance to use them doesn't make them useless.What is your objection anyway? |
 |
|
visakh16
Very Important crosS Applying yaK Herder
52326 Posts |
Posted - 2012-02-10 : 15:57:41
|
quote: Originally posted by X002548
quote: Originally posted by namman Are your serious xoo2548?
Yes I'm Serious...you got a good reason?What's your good reason to use schemas?And I'll betcha there's a way to do what ever you need tpo do without themBrett8-)Hint: Want your questions answered fast? Follow the direction in this linkhttp://weblogs.sqlteam.com/brettk/archive/2005/05/25/5276.aspxWant to help yourself?http://msdn.microsoft.com/en-us/library/ms130214.aspxhttp://weblogs.sqlteam.com/brettk/http://brettkaiser.blogspot.com/
some of things which immediately comes to my mind - Logically organising objects
- customised security for subset of objects
- seperation of dev and qa environments for small systems (ie dev tables in one schema giving access to DEVELOPER roles, qa objects in another schema where DEVELOPERS have restricted access
- easy maintainence of security model,access etc
------------------------------------------------------------------------------------------------------SQL Server MVPhttp://visakhm.blogspot.com/ |
 |
|
robvolk
Most Valuable Yak
15732 Posts |
Posted - 2012-02-10 : 17:24:46
|
dbo is a pain in the ass from a security perspective. It inherits db_owner permissions which can't be removed, and it can't be dropped from the database. The last thing I need are developers performing DDL against dbo objects with those permissions, since that lets them drop the database too.Different schemas make code and object deployment easy. For example I can create a "deploy" schema to hold objects for a new version of code. I can test them under that schema without affecting the existing production code. If my tests succeed, I do some ALTER SCHEMA...TRANSFER commands to move the new code into the production schema. Nothing is dropped, altered, or recompiled, so it's blindingly fast, and it can be wrapped in a transaction and rolled back if there's a problem. It's a completely non-destructive method of deploying code or new table structures.You can also do bulk data operations with staging tables in a different schema. It's better than using sp_rename because all the constraints inherit the table's schema and don't have to be renamed along with it. It too uses ALTER SCHEMA...TRANSFER and gives the same performance as sp_rename or partition switching, since only metadata is affected.And frankly, if you don't see their utility and don't want to use them, then don't. But please stop pestering the rest of us to defend them to you. |
 |
|
X002548
Not Just a Number
15586 Posts |
Posted - 2012-02-10 : 23:12:00
|
hey, I'm here to learn like everyone else. I also want to know that what makes sense is what is propagated to the community.>> The last thing I need are developers performing DDL against dbo objects with those permissions, I don't allow developers that level of accessAnd as far as promotion of code...I use a project lifecycle I see no need to change...DEV to QA to UAT to PRODI will read on my ownNo more talk about schemas from meBrett8-)Hint: Want your questions answered fast? Follow the direction in this linkhttp://weblogs.sqlteam.com/brettk/archive/2005/05/25/5276.aspxWant to help yourself?http://msdn.microsoft.com/en-us/library/ms130214.aspxhttp://weblogs.sqlteam.com/brettk/http://brettkaiser.blogspot.com/ |
 |
|
|
|
|
|
|