• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 259
  • Last Modified:

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
0
hefterr
Asked:
hefterr
  • 2
  • 2
1 Solution
 
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
 
JestersGrindCommented:
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
 
hefterrAuthor Commented:
Thanks!
0

Featured Post

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

  • 2
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now