SQL Serverの同義語は、ローカルまたはリモートサーバーに存在するデータベースオブジェクトに代替名を付けるデータベースオブジェクトです。また、ベースオブジェクトの変更からアプリケーションを保護するための抽象化レイヤーを提供します。
T-SQLスクリプトでは、データベースオブジェクトを参照するために3つの部分からなる名前を使用します。形式は次のとおりです。
[データベース]。[スキーマ]。[オブジェクト]
たとえば、次のデータベースインフラストラクチャがあるとします。
- データベース名:[Azuredemodatabase]
- スキーム:[SalesLT]
- オブジェクト(テーブル名):製品
3部構成の名前のSELECTステートメントは次のとおりです。
SELECT [ProductID]
,[Name]
,[ProductNumber]
,[Color]
,[StandardCost]
,[ListPrice]
,[Size]
,[Weight]
,[ProductCategoryID]
,[ProductModelID]
,[SellStartDate]
,[SellEndDate]
,[DiscontinuedDate]
,[ThumbNailPhoto]
,[ThumbnailPhotoFileName]
,[rowguid]
,[ModifiedDate]
FROM [Azuredemodatabase].[SalesLT].[Product]
同様に、リモートサーバーは4部構成の命名規則を使用します。追加の部分は[リモートサーバー名]です。したがって、形式は次のようになります
[サーバー名]。[データベース]。[スキーマ]。[オブジェクト]。
[SalesLT]。[Product]の名前を変更する必要があるとします。 テーブルから[ProductData] 。
このテーブルは、複数のストアドプロシージャ、関数、およびビューで参照されます。したがって、テーブルの最新の名前を使用するには、クエリまたはクライアントアプリケーションでこのような参照をすべて変更する必要があります。
データベースオブジェクトを参照するシノニムを作成し、SQLクエリで使用できます。変更が発生した場合は、シノニム定義を再作成するだけで済みます。シノニムを使用しているため、クエリ内のオブジェクト参照を変更する必要はありません。
別のケースでは、テーブル[Azuredemodatabase]。[SalesLT]。[Product]を指すシノニムを作成します。次に、テーブルを削除して、同様の名前のビューを作成します。この場合、オブジェクトのバインドはオブジェクト名で行われるため、シノニムは自動的にビューを参照します。
オブジェクトを別のデータベースに移動する場合、シノニムは変更を行う際の労力を最小限に抑えるのに役立ちます。シノニムを再作成すると、すべてのSQLクエリが自動的に最新のオブジェクトの場所を取得します。
シノニムを使用して、データベースオブジェクトの名前を隠すこともできます。ユーザーは、ベーステーブルを照会する代わりに、結果を取得するためにシノニムを照会できます。
次のオブジェクトのSQLServerでシノニムを定義できます。
- ユーザー定義テーブル
- ストアドプロシージャ
- 表示
- スカラーおよびインラインのテーブル値関数
- ローカルおよびグローバル一時テーブル
- CLRストアドプロシージャ、関数(テーブル値、集計、スカラー)
注:同義語名はデータベース内で一意である必要があります。
SQLServerでシノニムを使用する場所
Select、Update、Execute、Insert、Delete、sub-queriesなどの同義語をT-SQLステートメントで使用できます。
ただし、CreateやAlterなどのデータ定義言語(DDL)ステートメントで類義語を使用することはできません。また、同義語は、チェック制約、計算列、デフォルト式、ルール式、スキーマバインドビュー、および関数には適していません。
ローカルサーバーのSQLServerでシノニムを作成する
SQL Serverでシノニムを作成するには、CREATESYNONYMステートメントを使用します。構文は次のとおりです。
CREATE SYNONYM <synonym_name, sysname, sample_synonym>
FOR <schema_name, sysname, Production>.<object_name, sysname, Product>
GO
たとえば、同義語 [MyProductCatalog]を作成しましょう。 [Azuredemodatabase]。[SalesLT]。[Product] 。
CREATE SYNONYM MyProductCatalog FOR [Azuredemodatabase].[SalesLT].[Product]
作成したら、以下に示すように、テーブル名をシノニムに置き換えることができます。これは、CREATESYNONYMステートメントで参照したベーステーブルを内部的に参照します。
SELECT [ProductID]
,[Name]
,[ProductNumber]
,[Color]
,[StandardCost]
,[ListPrice]
,[Size]
,[Weight]
,[ProductCategoryID]
,[ProductModelID]
,[SellStartDate]
,[SellEndDate]
,[DiscontinuedDate]
,[ThumbNailPhoto]
,[ThumbnailPhotoFileName]
,[rowguid]
,[ModifiedDate]
FROM MyProductCatalog
リモートサーバー上のデータベースにシノニムを作成する
オブジェクトがリモートサーバー[ABC]に存在するとします。シノニムを作成して、クエリで4つの部分からなる名前を指定しないようにすることができます。以下のクエリでは、ベースオブジェクトは[MyRemoteServer]にあります:
EXEC sp_addlinkedserver MyRemoteServer;
GO
USE tempdb;
GO
CREATE SYNONYM MyProductCatalog FOR MyRemoteServer.[Azuredemodatabase].[SalesLT].[Product]
GO
SQL ServerManagementStudioを使用したシノニムの作成
シノニムを作成するには、SQL ServerManagementStudioのGUIを使用できます。
- SQLインスタンスに接続し、データベースを展開して、Synonymsフォルダーに移動します。
- それを右クリックして、[新しい同義語]を選択します。
- シノニム名、シノニムスキーマ、データベース名、オブジェクトスキーマ、オブジェクトタイプ、および名前に必要な詳細を入力します。
この例では、テーブルスキーマと同じように、スキーマ[HumanResources]にシノニムを作成します。
スクリプトをクリックします 以下のような同等のT-SQLスクリプトを取得するには:
USE [AdventureWorks2017]
GO
CREATE SYNONYM [HumanResources].[MyEmpData] FOR
[AdventureWorks2017].[HumanResources].[Employee]
GO
ユーザー定義関数の同義語
まず、 UDF dbo.TestSynonymを作成します 以下のスクリプトを使用します:
CREATE FUNCTION dbo.TestSynonyn (@ID int)
RETURNS int
AS
BEGIN
IF @ID < 0
BEGIN
SET @ID=100
END
RETURN(@ID);
END;
GO
次に、 dbo.UDFTestという名前で同義語を作成します 。シノニムを使用してUDFを呼び出し、クエリ結果を取得できます。
CREATE SYNONYM dbo.UDFTest FOR dbo.TestSynonyn;
GO
Declare @ID INT=-10
Select @ID as OrigninalValue, dbo.UDFTest(@ID) as modifiedValue
ステートメントと同義語の更新
SQLテーブルの値を更新するとします。同義語を定義している場合は、それを利用することもできます。たとえば、以下の更新ステートメントでは、同義語[Perofmancetest]を使用しています。 SQLテーブル名の代わりに:
Update performancetest set [Name]='Updated New value' where ID=1
同義語の削除
DROP SYNONYMステートメントを使用して、データベース内の特定のシノニムを削除できます。以下のクエリは[EmpDataを削除します ] AdventureWorks2017 データベース:
Use AdventureWorks2017
Drop Synonym EmpData
SQLServerのデータベースシノニムのリストを取得する
データベース内の既存のシノニムとそのベースオブジェクトを知りたいとします。 sys.synonymsにクエリを実行できます それぞれのデータベースのシステムカタログビュー:
SELECT
name,
base_object_name,
type
FROM
sys.synonyms
クエリ出力には、次の情報が表示されます。
- 同義語名
- ベースオブジェクト(3部または4部のオブジェクト名)
- オブジェクトタイプ(SN =同義語)
シノニムのベースオブジェクトを変更するとどうなりますか?
同義語のベースオブジェクトを変更した場合の影響について考えてみましょう。いくつかのタスクを実行するためのクエリがあります:
- シノニムを作成します(シノニム名は[dbo]。[EmpData] ベースオブジェクトの場合[AdventureWorks2017]。[DBO]。[Emp] )
- ベースオブジェクト(テーブル)をドロップします[AdventureWorks2017]。[DBO]。[Emp]
- [AdventureWorks2017]データベースに[DBO]。[Emp]という名前のビューを作成します。
USE [AdventureWorks2017]
GO
CREATE SYNONYM [dbo].[EmpData] FOR [AdventureWorks2017].[DBO].[Emp]
GO
Drop table [AdventureWorks2017].[DBO].[Emp]
Go
Create view [DBO].[Emp]
as
Select * from dbo.Employee
go
前述のように、シノニムはその名前を使用してオブジェクトをバインドします。したがって、テーブルではなくビューを指す必要があります。この場合、[dbo]。[Emp]テーブルは存在しません。
以下に示すように、これは [AdventureWorks2017]のビューです。 データベース。
または、 OBJECTPROPERTYEX()を使用することもできます シノニムのオブジェクトベースタイプを確認するには:
SELECT OBJECTPROPERTYEX(OBJECT_ID('Emp'), 'BaseType') AS BaseType;
GO
ここで、Baseタイプはデータベースビューを参照しています。 SQLテーブルの場合、 Uを取得します 出力で。
同義語はクエリのパフォーマンスに悪影響を及ぼしますか?
多くのデータベースの専門家は、SQLServerで使用同義語を使用しないことを好みます。彼らのポイントは、SQLServerがシノニムからベーステーブルを解決するために追加の手順を実行する必要があるということです。したがって、悪影響が生じる可能性があります。
クエリのパフォーマンスをテストしてみましょう。テーブル名とシノニムからレコードを取得します:
Create table TestTable
(
ID int,
[Name] varchar(20)
)
Insert into TestTable values (1, 'Temporary Data')
GO 10000
Create synonym performancetest for TestTable
SET STATISTICS IO ON;
Select * from TestTable
Go
Select * from performancetest
まず、実際の実行計画を確認しましょう。両方のクエリバッチの実行プランとオペレーターのコストは同じです:
同様に、両方のクエリには、目的の出力を取得するための41の論理読み取りと1つのスキャンカウントがあります。
SQL Serverは、クエリ実行のバインドフェーズでシノニムベースオブジェクト名を解決します。これは、クエリ最適化フェーズの前に発生します。したがって、同様の実行プランが表示され、パフォーマンスへの影響はありません。したがって、同義語を使用して、頻繁にアクセスされるオブジェクトの長い3部構成または4部構成の名前を回避できます。クエリのパフォーマンスには影響しません。
テーブル、ストアドプロシージャ、関数、ビューなどのオブジェクトごとにシノニムを作成することを意味するものではありません。最も頻繁にアクセスされるオブジェクトに使用して、クエリですばやく参照できます。
結論
SQLServerの同義語は有益な場合があります。 3部構成または4部構成の長い名前を避けることにより、データベースオブジェクト名を単純化します。これらは、ローカルオブジェクトとリモートオブジェクトの両方を参照するために使用できます。パフォーマンスの問題は発生しません。したがって、クエリを作成する際の柔軟性のためにそれらを使用することを検討できます。ただし、何よりも、SQLスクリプトで頻繁に使用されるオブジェクトの同義語のみを定義することです。