Usage of "Schema" names

Hi,
I am somewhat a newbie to SQL Server administration as I am now doing everything for a very small company.

I have a database the has the need for 2 "Organization" tables.  One is a "Customer Organization" table (What organization the customer belongs to).  The other is a "Global Organization" table.  Let's accept that they have to be different tables.

Within a database, what are the ramifications between the 2 sets of names:
Database: myCompany
table:  dbo.Cust_organization
table:  dbo_Global_Organization
OR
Database: myCompany
table:  Cust.Organization
table:  Global.Organization

And what is the ramification of making a separate database (when would I do that)?
Database : myCompany
table: dbo.Organization

Database : Global
table: dbo.Organization

Any advise would be appreciated,
hefterr
LVL 1
hefterrAsked:
Who is Participating?
 
JestersGrindConnect With a Mentor Commented:
I was referring to user security.  In most environments that I have worked in, DBAs have full access to production and developers have none, but every environment is different.  

Q:  Is this a common procedure for just "grouping" as this is what I would be using it for.
The behavior changed in SQL 2005.  Before that schemas were tied to a specific user.   Now they are independent and are really used more for organization than anything else.  Although, they can also simplify security too.  This is a pretty good article about it.

http://blog.sqlauthority.com/2009/09/07/sql-server-importance-of-database-schemas-in-sql-server/

Q:  If a table was shared by different sites/applications, would it be more of a candidate for a separate DB?  Or is that not significant?
It really depends.  Typically, I like to use one database per application, but I have seen implementations where customers were separated out to separate databases.  I've never thought that was a good practice.  As long as your customers can only see their data and not any other customer's data, it doesn't really matter how you store it.

Greg




0
 
JestersGrindCommented:
The difference is largely personal choice.  It depends on how your security is setup.  To give you another option, you could even have one table with a column that differentiates between customer and global, if the columns are the same.  

Using different schemas allows a logical grouping of objects and you can assign permission to the schema to only allow users to use that schema.  

With separate tables, you can still assign permissions to only the appropriate table, but you would have to assign permissions individually to each object instead of one like the schema method.

With separate databases, you can complete separate the data.  This might mean that you have duplicate tables in each to accommodate the design.  Also, need separate backups, etc...

Greg

0
 
hefterrAuthor Commented:
Hi JestersGrind,
Thanks for the quick response.

On the topic of security, as a web application all public users have the same security.  So you are talking about developers, DBA I assume?

...Using different schemas allows a logical grouping of objects and you can assign permission to the schema to only allow users to use that schema.  
Q:  Is this a common procedure for just "grouping" as this is what I would be using it for.

Q:  If a table was shared by different sites/applications, would it be more of a candidate for a separate DB?  Or is that not significant?

Thanks again,
hefterr

0
 
hefterrAuthor Commented:
Thanks!
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.