This is a simple question yet I was unable to find any information at all about this.
Is it possible to have sub-schemas in SQL Server 2005/2008?
Example:
Having a HR (Human Resources) schema with a sub-schema called Training (with tables related to this). It would end up like HR.Training.* where * would be the tables.
No. You could fake this with roles by putting different users into different roles and allowing those roles to use objects.
Maybe you could fake it in the naming of the schema, like HR_Training.* and HR_Reviews.* and so forth. Cheesy, I know.
Are you coming from an Oracle background by any chance ? Oracle has the concept of Schemas I believe. In SQL Server the closest equivalent is a Database.
You can cross-query from one database to another on the same SQL server very easily and that would give you virtually the same kind of calling syntax
e.g server.database.owner.object
In you case it might look like HRSvr.HR.dbo.xxx and HRSvr.Training.dbo.xxxx.
yea you can make schemas but doesn't seem like you can make sub-schemas. I come from IBM db2 background but our IT folks here don't seen to know that you can other schemas beside the default 'dbo'.
Related
I am looking at a way to establish a few tables in my database.
I want to connect every user that logs in to the comments that they leave. There should be 2 or 3 tables. But I have no understanding on how to achieve this. Does anyone know where I can read and learn about how to build table relationships effectively?
You should understand how 'joins' work. They will define how you access your data later.
Check out this site:
http://www.sql-tutorial.net/SQL-JOIN.asp
Even if you don't have MS Access, this is a good tutorial for getting a handle on creating tables and defining relationships.
http://office.microsoft.com/en-us/training/design-tables-for-a-new-access-2007-database-RZ010286445.aspx
Also, "SQL for Dummies" is a great reference to have. Get a used copy on Amazon.
Here's a walk-through for SQL Server 2005: http://dotnetguts.blogspot.com/2007/10/basics-of-sql-server-2005.html
Is there a way to show table relationships as can be done in Access? Consider two tables:
Services
serviceid
application id
Application
application id
application name
I have already set up the diagram.
When opening the table service id I want to see the related application details like in Access.
Is this possible?
First of all, you an always use access to connect to SQL Server and see relationships through it.
The built in database diagram feature will also show relationships, as you describe. You can find it under the database in question in the diagrams node.
Here is an article about different options to produce an ERD.
Update:
In order to see results, I would suggest using access to connect to SQL Server, as described in the link above.
The SQL Server GUI does not have this facility, and if you want to see results from several tables you need to write the SQL queries that will generate the wanted data.
You could also create a VIEW:
CREATE VIEW ServicesApplication AS
SELECT S.ServiceID, S.ApplicationID, A.ApplicationName
FROM Services AS S
LEFT JOIN Applications AS A
ON S.ApplicationID = A.ApplicationID
That way you can always access the coupled data easily by manipulating the ServicesApplication view instead of the separate tables.
SQL 2008 doesn't have anything built in to provide that functionality. Almost sounds like you're looking to trouble shoot an application by looking at database entries...if thats true I'd recommend learning tsql well enough to write these statements as you need and not rely on another application to provide a visual interface. heh, if I'm completely wrong with that, ignore me :)
If you still want the 3rd party application route...I beleive TOAD has that functionality within it, though I've never connected it to a MS SQL 2008 server before. There are other third party applications out there that will provide this functionality, though I imagine they aren't all free. If you're looking for a free solution and already have Access going, Oded probably has the best idea here...connect MS access to the SQL 2008 server (linked tables) and use MS access to provide the features you want from ms access :)
I'm no beginner to using SQL databases, and in particular SQL Server. However, I've been primarily a SQL 2000 guy and I've always been confused by schemas in 2005+. Yes, I know the basic definition of a schema, but what are they really used for in a typical SQL Server deployment?
I've always just used the default schema. Why would I want to create specialized schemas? Why would I assign any of the built-in schemas?
EDIT: To clarify, I guess I'm looking for the benefits of schemas. If you're only going to use it as a security scheme, it seems like database roles already filled that.. er.. um.. role. And using it a as a namespace specifier seems to have been something you could have done with ownership (dbo versus user, etc..).
I guess what I'm getting at is, what do Schemas do that you couldn't do with owners and roles? What are their specifc benefits?
Schemas logically group tables, procedures, views together. All employee-related objects in the employee schema, etc.
You can also give permissions to just one schema, so that users can only see the schema they have access to and nothing else.
Just like Namespace of C# codes.
They can also provide a kind of naming collision protection for plugin data. For example, the new Change Data Capture feature in SQL Server 2008 puts the tables it uses in a separate cdc schema. This way, they don't have to worry about a naming conflict between a CDC table and a real table used in the database, and for that matter can deliberately shadow the names of the real tables.
I know it's an old thread, but I just looked into schemas myself and think the following could be another good candidate for schema usage:
In a Datawarehouse, with data coming from different sources, you can use a different schema for each source, and then e.g. control access based on the schemas. Also avoids the possible naming collisions between the various source, as another poster replied above.
If you keep your schema discrete then you can scale an application by deploying a given schema to a new DB server. (This assumes you have an application or system which is big enough to have distinct functionality).
An example, consider a system that performs logging. All logging tables and SPs are in the [logging] schema. Logging is a good example because it is rare (if ever) that other functionality in the system would overlap (that is join to) objects in the logging schema.
A hint for using this technique -- have a different connection string for each schema in your application / system. Then you deploy the schema elements to a new server and change your connection string when you need to scale.
At an ORACLE shop I worked at for many years, schemas were used to encapsulate procedures (and packages) that applied to different front-end applications. A different 'API' schema for each application often made sense as the use cases, users, and system requirements were quite different. For example, one 'API' schema was for a development/configuration application only to be used by developers. Another 'API' schema was for accessing the client data via views and procedures (searches). Another 'API' schema encapsulated code that was used for synchronizing development/configuration and client data with an application that had it's own database. Some of these 'API' schemas, under the covers, would still share common procedures and functions with eachother (via other 'COMMON' schemas) where it made sense.
I will say that not having a schema is probably not the end of the world, though it can be very helpful. Really, it is the lack of packages in SQL Server that really creates problems in my mind... but that is a different topic.
I tend to agree with Brent on this one... see this discussion here. http://www.brentozar.com/archive/2010/05/why-use-schemas/
In short... schemas aren't terribly useful except for very specific use cases. Makes things messy. Do not use them if you can help it. And try to obey the K(eep) I(t) S(imple) S(tupid) rule.
I don't see the benefit in aliasing out users tied to Schemas. Here is why....
Most people connect their user accounts to databases via roles initially, As soon as you assign a user to either the sysadmin, or the database role db_owner, in any form, that account is either aliased to the "dbo" user account, or has full permissions on a database. Once that occurs, no matter how you assign yourself to a scheme beyond your default schema (which has the same name as your user account), those dbo rights are assigned to those object you create under your user and schema. Its kinda pointless.....and just a namespace and confuses true ownership on those objects. Its poor design if you ask me....whomever designed it.
What they should have done is created "Groups", and thrown out schemas and role and just allow you to tier groups of groups in any combination you like, then at each tier tell the system if permissions are inherited, denied, or overwritten with custom ones. This would have been so much more intuitive and allowed DBA's to better control who the real owners are on those objects. Right now its implied in most cases the dbo default SQL Server user has those rights....not the user.
I think schemas are like a lot of new features (whether to SQL Server or any other software tool). You need to carefully evaluate whether the benefit of adding it to your development kit offsets the loss of simplicity in design and implementation.
It looks to me like schemas are roughly equivalent to optional namespaces. If you're in a situation where object names are colliding and the granularity of permissions is not fine enough, here's a tool. (I'd be inclined to say there might be design issues that should be dealt with at a more fundamental level first.)
The problem can be that, if it's there, some developers will start casually using it for short-term benefit; and once it's in there it can become kudzu.
In SQL Server 2000, objects created were linked to that particular user, like if a user, say
Sam creates an object, say, Employees, that table would appear like: Sam.Employees. What
about if Sam is leaving the compnay or moves to so other business area. As soon you delete
the user Sam, what would happen to Sam.Employees table? Probably, you would have to change
the ownership first from Sam.Employees to dbo.Employess. Schema provides a solution to
overcome this problem. Sam can create all his object within a schemam such as Emp_Schema.
Now, if he creates an object Employees within Emp_Schema then the object would be
referred to as Emp_Schema.Employees. Even if the user account Sam needs to be deleted, the
schema would not be affected.
development - each of our devs get their own schema as a sandbox to play in.
Here a good implementation example of using schemas with SQL Server. We had several ms-access applications. We wanted to convert those to a ASP.NET App portal. Every ms-access application is written as an App for that portal. Every ms-access application has its own database tables. Some of those are related, we put those in the common dbo schema of SQL Server. The rest gets its own schemas. That way if we want to know what tables belong to an App on the ASP.NET app portal that can easily be navigated, visualised and maintained.
How can we find out that how many applications are there in a database?
Not entirely sure what you're asking for here. I'm assuming you mean "Applications written using SQL Server 2005 as the database.".
If that's what you want to know, I don't know of any single place you could get that information by it's always a good idea to try starting here.
Do you mean stored procedures? You can have multiple applications using the same login credentials accessing a given database from the same web server, so you can't simply count databases or tables to get that number.
Are there any good database schema comparison tools out there that support Sybase SQL Anywhere version 10? I've seen a litany of them for SQL Server, a few for MySQL and Oracle, but nothing that supports SQL Anywhere correctly.
I tried using DB Solo, but it turned all my non-unique indexes into unique ones, and I didn't see any options to change that.
If you are willing to download SQL Anywhere Version 11, and Compare It!, check out the comparison technique shown here:
http://sqlanywhere.blogspot.com/2008/08/comparing-database-schemas.html
You don't have to upgrade your SQL Anywhere Version 10 database.
The new kid on the block is Qwerybuilder. It supports SQL Server, Sybase ASE, Sybase SQL Anywhere and Oracle. I've used it successfully with SQL Anywhere to track schema changes.
Two I've come across that support SQL Anywhere:
Upscene Database Workbench - http://www.upscene.com/products.dbw.sqlanywhere.php
Aquafold - http://www.aquafold.com/index-sybaseany.html
Each one appears has a schema comparison tool, however I have not used either to compare schemas.
SQLDelta is awesome. It is for SQL Server. I've used it with SQL 2000 and 2005. It will compare stored procedures, tables, views, permissions, indexes, etc. It can also compare data between tables I believe. You can sync the changes or generate SQL Scripts for later use. I use it often to script out db changes in development to production.
Ah...missed the Sybase remark. Not sure if SQLDelta can talk to it..but I'd probably give it a shot since Sybase is similar.
Try erwin (CA AllFusion ERwin Data Modeler). It supports quite a lot of different DBs, including SQL Anywhere, and is quite good in reverse/forward engineering and schema comparison. However, you may find it a bit too complex to use for the comparison...
I use SQL Data Compare from Red Gate along with SQL Compare the data compare allows you to Compare the contents of two databases and Automatically synchronize your data.
SQL compare allows you to do the same but with the database tables. Nice GUI on each and very easy setup. they also work on a remote database.
There not cheap but each has a 30 trail so you can get a feel if you like it or not.
Sybase PowerDesigner can also Compare or Merge your Database Schema.
It can also Load the Schema from various Databases by ODBC if you have Schema generation Scripts you can also load them into a Model.
Its an expensive tool but great to document and develop you schema changes IMHO.
Breck Carter's idea is a good one. For quick scans, I have an old product that is called DBDelta. I have it installed on an old Windows 2000 machine because the install I have will not work on an XP machine. It's a very small app that compares two SQL Anywhere databases across an ODBC connection.
I've done some searches to try and find a later copy, but have not been able to. The developer was Charles Butcher. I think he supported it for a while and then stopped back in 2002 or so.
I'll continue to look for a link. If I find something I will post it here.
QweryBuilder 5.5.0 will allow you to compare all procedures, functions, views, tables and triggers in one shot. This release is scheduled for mid May, 2010.
It hasn't been finalized yet but we are also looking at adding an option to turn the diff results into a script that can be executed on a target database.