T-SQL の名前付けの問題
適用対象: SQL Server Azure SQL Database Azure SQL Managed Instance Microsoft Fabric SQL Database
データベース プロジェクトで T-SQL コードを分析すると、1 つまたは複数の警告が名前付けの問題として分類される場合があります。 次の状況を回避するには、名前付けの問題に対処する必要があります:
- オブジェクトに指定した名前は、システム オブジェクトの名前と競合する可能性があります。
- 指定した名前は、常にエスケープ文字で囲む必要があります (SQL Server では '[' および ']')。
- 指定した名前は、コードの読み取りと理解を試みる他のユーザーを混乱させる可能性があります。
- SQL Server の今後のリリースでコードを実行すると、そのコードが中断する可能性があります。
通常、変更できない他のアプリケーションが現在の名前に依存する場合は、名前付けの問題を抑制できます。
指定された規則では、次の名前付けの問題が特定されます:
- SR0011: オブジェクト名に特殊文字を使用しないようにする
- SR0012: 型名に予約語を使用しないようにする
- SR0016: ストアド プロシージャの名前の先頭に sp_ を使用しないようにする
SR0011: オブジェクト名に特殊文字を使用しないようにする
次の表の任意の文字を使用してデータベース オブジェクトに名前を付ける場合、そのオブジェクトを参照するだけでなく、そのオブジェクトの名前を含むコードを読み取ることもより困難になります:
文字 | 説明 |
---|---|
|
空白文字 |
[ |
左角かっこ |
] |
右角かっこ |
' |
単一引用符 |
" |
二重引用符 |
違反の修正方法
この問題を解決するには、オブジェクト名からすべての特殊文字を削除する必要があります。 オブジェクトがデータベース プロジェクト内の他の場所 (データベース単体テストなど) で参照されている場合は、データベース リファクタリングを使用してリファレンスを更新する必要があります。 詳細については、「データベース オブジェクトへのすべてのリファレンスの名前を変更する」を参照してください。
例
最初の例では、テーブルの名前に特殊文字を含む列が含まれています。 2 番目の例では、名前に特殊文字が含まれません。
CREATE TABLE [dbo].[TableWithProblemColumn]
(
[ID] INT NOT NULL IDENTITY(0, 1),
[Small'String] VARCHAR(10)
)
ON [PRIMARY]
CREATE TABLE [dbo].[FixedTable]
(
[ID] INT NOT NULL IDENTITY(0, 1),
[SmallString] VARCHAR(10)
)
ON [PRIMARY]
SR0012: 型名に予約語を使用しないようにする
リーダーがデータベース コードを理解しにくくなるため、ユーザー定義型の名前に予約語を使用しないようにする必要があります。 SQL Server では、区切り識別子を使用する場合にのみ、識別子とオブジェクト名として予約語を使用できます。 詳細については、予約キーワードの全一覧 をご覧ください。
違反の修正方法
ユーザー定義型またはオブジェクト名の名前を変更する必要があります。
例
最初の例は、この警告をトリガーするユーザー定義型の定義を示しています。 2 番目の例は、ユーザー定義型を修正して問題を解決する 1 つの方法を示しています。
-- Potential misuse of a keyword as a type name
CREATE TYPE Alter
FROM nvarchar(11) NOT NULL;
-- Corrected type name
CREATE TYPE AlterType
FROM nvarchar(11) NOT NULL;
SR0016: ストアド プロシージャの名前の先頭に sp_ を使用しないようにする
SQL Server では、sp_
のプレフィックスはシステム ストアド プロシージャを指定します。 そのプレフィックスをストアド プロシージャに使用すると、プロシージャの名前が、将来作成されるシステム ストアド プロシージャの名前と競合する可能性があります。 このような競合が発生した場合、アプリケーションがスキーマによる参照を修飾せずにプロシージャを参照すると、アプリケーションが中断する可能性があります。 このような場合、名前はプロシージャではなくシステム プロシージャにバインドされます。
違反の修正方法
この問題を解決するには、sp_
を別のプレフィックスに置き換えてユーザー ストアド プロシージャを指定するか、プレフィックスをまったく使用しない必要があります。
例
最初の例では、プロシージャ名によってこの警告が発行されます。 2 番目の例では、プロシージャは sp_
ではなく usp_
のプレフィックスを使用し、警告を回避します。
CREATE PROCEDURE [dbo].[sp_procWithWarning]
(
@Value1 INT,
)
AS
BEGIN
-- Additional statements here
RETURN 0;
END
CREATE PROCEDURE [dbo].[usp_procFixed]
(
@Value1 INT,
)
AS
BEGIN
-- Additional statements here
RETURN 0;
END