I want to ask whether it better to use Synonym or the actual name of the table to tune the performance of a SQL query?
A synonym is a label to an actual database object. They are used as a layer of abstraction. The main use is for referencing objects in other schemas or remote databases. Using a synonym means we don't have to change out code when we move in different environments.
The performance hit of using a synonym is the look up. Given an object name in a query the optimizer will look for matching objects in this order:
a table or view in the referenced schema (default is current schema)
a private synonym in the referenced schema
a public synonym
So, if our current schema has a table T23 the database will use that in our query rather than the table referenced by public synonym T23.
Depending on the state of the data dictionary the cost of this look up should range from utterly completely negligible to more-or-less negligible.
Using a synonym will not affect the performance of the actual query. That is, these two queries will have the same execution profile:
select * from synonym_of_some_table;
select * from other_user.some_table#remote_db;
"even it the data in the table is very large" ?
Yes, even if the data in the table is very large. Using a synonym won't affect retrieving the data either way. Synonyms are not like views, which can make tuning a lot harder.
Related
I'm new to Azure and not great with SQL so any help would be greatly appreciated.
I have a Database where each user has a Schema. Each Schema has identically structured tables with the same name, say "Table".
I now require a View in another Schema which provides a read-only union of all the rows from all the tables Table.
I was successful in creating a Schema, say Views, handling its permissions and creating a View, "TableView", with the following SQL from Partitioned Views # learn.microsoft.com:
CREATE VIEW Views.TableView
AS
SELECT *
FROM Schema1.Table
UNION ALL
SELECT *
FROM Schema2.Table
UNION ALL
SELECT *
FROM Schema3.Table
...
GO
I now wish for this View to be dynamic as future Schemas (SchemaX) are added or even possibly removed without having to repeatedly DROP and CREATE TableView over and over.
Is it possible to create the View in such a way that it would automatically query all tables with the same name? Or perhaps there is some way to 'add' an additional table post creation?
I can get a list of all SchemaX.Table by querying INFORMATION_SCHEMA, but other than having a python script DROP and CREATE the View again I am lost.
Thanks
Thanks for #larnu's comments, it's very useful and professional:
To achieve this dynamically, it would be impossible to do in a VIEW.
You would have to use a stored procedure, and that means you can't do
simple things like SELECT from it, making it far harder to use.
Instead of having 17 tables, all identical, on different schemas you
have one table, with a column BusinessName. Instead of
MySmartCompany.Mytable you have a column in the table dbo.MyTable (or
your generic schema), called BusinessName which has the value 'MySmartCompany'.
This also can be beneficial to other community members.
Following is my schema detail:
DB_A : schema_1, schema_2, schema_3
DB_B : schema_3
some procedures in schema_3 access resources(table, view, sp) from schema_1 and schema_2.
All procedures in schema_3 are same on both the dbs. How do I access schema_1 from schema_3 for both the dbs.
Now I can hard code DB_A in my procedures but when I move code to client machine, it will create a problem since DB_A may not be same(one of the reason being client is miser and having QA, Dev and Prod on same machine).
Second option is getting DB_A name as a parameter, but it will make all the schema_3 SPs dynamic (as I did not get any method to access something like #DBName.schema_name.ResourceName).
Third option is creating linked servers, which again do not solve my problem because of same reason as first.
Any idea how to proceed, where I do not want my procedures to be dynamic just because 80% of them are straight.
Edit Start:
So I can restate it as I have multiple databases with a database having resources (table/view/schema) which needs to be shared and then having other databases (one or more) which have stored procedures which computes on data from shared database and self database.
Shared database name is not going to be constant on all the environments and I want to change them(environment specific). I have come out with a solution where I will be creating synonym for all the shared resources and all procedures will be using them, that way they are all referring to shared resources from first database.
For each installation I need to modify synonyms definition to reflect correct share database name. Is there any SYNONYM For Database Name, that way I will have way less synonyms to handle.
Well the best choice I found is as follows.
Create Synonym (independent database DB_B) for individual objects (in shared database DB_A) with same name in same schema. That way your existing procedures need not change, and will work as required. Synonym gives a good reference on this. I will soon be creating an app to ease creating synonyms for these kind of situations.
CREATE SYNONYM DB_B.schema_1.proc_1 FOR DB_A.schema_1.proc_1
You can run your procedure in DB_A and create a view from DB_A to DB_B:
create view dbo.vw_B_Schema_3
as
select *
from DB_B.dbo.Schema_3
You'd have to create three versions of the view (dev, QA, prod.) But the view will be the only difference: procedure definitions can remain identical.
If DB_A and DB_B are on same server, only sure you that the login have permission in two database.
Now, use [database].[schema].[object], when you use object of others database
eg: I have two database, ("helpdesk", "intranet")
from heldesk to intranet
create view dbo.users
as
select login, name, lastname
from intranet.dbo.user // [database].[schema].[object] user is a table in dbo schema from intranet database.
where status = 1
;
I know databases aren't supported by CREATE SYNONYM, but I'm looking to achieve the functionality this would provide.
We've got Database A which contains views to tables on Database B. The trouble is "Database B" isn't always called "Database B". We use database projects for deployments, which at the moment fall over with an "Invalid Object Name" error if there isn't a "Database B".
The workaround at the moment is to open up the .dbschema file and do a find and replace. I guess another option would be to create a load of table synonyms.
What's the best way of changing the database a number of views reference without changing each view individually?
Thanks
Synonyms are a good way to do this. You have to create the synonyms at the object level though (as you've discovered). An easy way to do this would be to write a script that runs through the list of tables in DatabaseB (from your example) and creates a synonym for each one in DatabaseA. Keep the name of the synonym the same so the code in your views doesn't have to change. For instance, you you have tbl_a, tbl_b, and tbl_c in DatabaseB, you'd want your script to eventually do the following:
create synonym [otherDb].[tbl_a] for [DatabaseB].[schemaB].[tbl_a]
create synonym [otherDb].[tbl_b] for [DatabaseB].[schemaB].[tbl_b]
create synonym [otherDb].[tbl_c] for [DatabaseB].[schemaB].[tbl_c]
Now, in your view code, you'll always use [otherDb].[tbl_a], [otherDb].[tbl_b], and [otherDb].[tbl_c]. Hope this makes sense.
Last year I helped my current client with the implementation of a very similar design. We wrote a set of functions and stored procedures which generate the views automatically. Whenever you need to change the target database it generates the code to drop and recreate all of the views.
The code wasn't too difficult. It just uses the system tables to generate view code. I also wrote a Powershell prototype that uses SMO to do the same thing. The key is to have it automated to the point of requiring a single call so that you can do it easily and accurately.
We also included an exception table that used a pattern match of tables to exclude from view generation. It included a schema column and a table name column, each of which accepted LIKE patterns, so you could put "my_schema" and "%" to exclude all tables in the my_schema schema.
One master stored procedure accepted a target database name and would generate the entire script. Once the script is generated you can run it in SSMS or have that part automated as well.
This whole thing would be even easier if you just wanted to generate synonyms. We were using views so that we could change column lists, etc. and have the view DB look different than the target DB where needed.
Using a view to encapsulate a table whose name changes yearly (tablename_year) called "vw_Tablename_Current" so I don't have to change any procs that use the table to reflect the new table name, just the view.
This is temporary until I'm able to make deeper model changes. Is there any performance hit on wrapping a single table in a view like this?
Sql Server 2005
You can use a synonym as well which is cleaner
CREATE SYNONYM tablename FOR tablename_year;
No, there is no performance difference if the view is essentially a SELECT * FROM table
I read about temporary tables, global temporary tables and table variables. I understood it but could not imagine a condition when I have to use this. Please elaborate on when I should use the temporary table.
Most common scenario for using temporary tables is from within a stored procedure.
If there is logic inside a stored procedure which involves manipulation of data that cannot be done within a single query, then in such cases, the output of one query / intermediate results can be stored in a temporary table which then participates in further manipulation via joins etc to achieve the final result.
One common scenario in using temporary tables is to store the results of a SELECT INTO statement
The table variable is relatively new (introduced in SQL Server 2005 - as far as i can remember ) can be used instead of the temp table in most cases. Some differences between the two are discussed here
In a lot of cases, especially in OLTP applications, usage of temporary tables within your procedures means that you MAY possibly have business processing logic in your database and might be a consideration for you to re-look your design - especially in case of n tier systems having a separate business layer in their application.
The main difference between the three is a matter of lifetime and scope.
By a global table, I am assuming you mean a standard, run of the mill, table. Tables are used for storing persistent data. They are accessible to all logged in users. Any changes you make are visible to other users and vice versa.
A temporary table exist solely for storing data within a session. The best time to use temporary tables are when you need to store information within SQL server for use over a number of SQL transactions. Like a normal table, you'll create it, interact with it (insert/update/delete) and when you are done, you'll drop it. There are two differences between a table and a temporary table.
The temporary table is only visible to you. Even if someone else creates a temporary table with the same name, no one else will be able to see or affect your temporary table.
The temporary table exists for as long as you are logged in, unless you explicitly drop it. If you log out or are disconnected SQL Server will automatically clean it up for you. This also means the data is not persistent. If you create a temporary table in one session and log out, it will not be there when you log back in.
A table variable works like any variable within SQL Server. This is used for storing data for use in a single transaction. This is a relatively new feature of TSQL and is generally used for passing data between procedures - like passing an array. There are three differences between a table and a table variable.
Like a temporary table, it is only visible to you.
Because it is a variable, it can be passed around between stored procedures.
The temporary table only exists within the current transaction. Once SQL Server finishes a transaction (with the GO or END TRANSACTION statements) or it goes out of scope, it will be deallocated.
I personally avoid using temporary tables and table variables, for a few reasons. First, the syntax for them is Microsoft specific. If your program is going to interact with more than one RDBMS, don't use them. Also, temporary tables and table variables have a tendency to increase the complexity of some SQL queries. If your code can be accomplished using a simpler method, I'd recommend going with simple.