CLR 統合の概要

適用対象:SQL ServerAzure SQL Managed Instance

共通言語ランタイム (CLR) は .NET Framework の中核であり、すべての .NET Framework コードの実行環境を提供します。 CLR 内で実行されるコードは、 管理されたコードと呼ばれます。 CLR は、ジャストインタイム (JIT) コンパイル、メモリの割り当てと管理、タイプ セーフの設定、例外処理、スレッド管理、セキュリティなど、プログラムの実行に必要なさまざまな機能やサービスを備えています。 詳細については、 .NET Framework 開発ガイドを参照してください。

SQL Server でホストされている CLR (CLR 統合と呼ばれます) を使用すると、ストアド プロシージャ、トリガー、ユーザー定義関数、ユーザー定義型、およびユーザー定義集計をマネージド コードで作成できます。 マネージド コードは実行前にネイティブ コードにコンパイルされるため、一部のシナリオではパフォーマンスが大幅に向上します。

コード アクセス セキュリティ

SQL Server 2016 (13.x) 以前のバージョンでは、コード アクセス セキュリティ (CAS) によってアセンブリで特定の操作が実行されなくなります。

CLR では、セキュリティ境界としてサポートされなくなった、.NET Framework のコード アクセス セキュリティ (CAS) が使用されます。 PERMISSION_SET = SAFE で作成された CLR アセンブリが、外部のシステム リソースにアクセスし、非管理対象コードを呼び出し、sysadmin 特権を取得できる場合があります。 SQL Server 2017 (14.x) 以降のバージョンでは、sp_configure オプション、厳密なセキュリティにより CLR アセンブリのセキュリティが強化されます。 clr strict security は既定で有効になり、SAFE および EXTERNAL_ACCESS アセンブリを UNSAFE とマークされている場合と同様に扱います。 clr strict security オプションは、旧バージョンとの互換性のために無効にできますが、推奨されません。

すべてのアセンブリに対して、UNSAFE ASSEMBLY データベース内で master 権限が付与された対応するログインを持つ認定資格証または非対称キーで署名することをお勧めします。 SQL Server 管理者は、データベース エンジンが信頼するアセンブリのリストにアセンブリを追加することもできます。 詳細については、「sys.sp_add_trusted_assembly」を参照してください。

CLR 統合の利点

Transact-SQL は、データベース内の直接のデータ アクセスと操作用に設計されています。 Transact-SQL はデータ アクセスと管理に優れていますが、本格的なプログラミング言語ではありません。 たとえば、Transact-SQL では、配列、コレクション、for-each ループ、ビット シフト、またはクラスはサポートされていません。 これらのコンストラクトの一部は Transact-SQL でシミュレートできますが、マネージド コードではこれらのコンストラクトのサポートが統合されています。 シナリオによっては、この特性が、特定のデータベースの機能をマネージド コードに実装するかどうかの決め手となることがあります。

Visual Basic と C# では、カプセル化、継承、ポリモーフィズムなどのオブジェクト指向の機能が提供されます。 関連のあるコードは、簡単にクラスや名前空間に編成することができます。 大量のサーバー コードを使用している場合、これらの機能を使用すると、コードをより簡単に整理して管理できます。

マネージド コードは、計算や複雑な実行ロジックに Transact-SQL よりも適しており、文字列処理や正規表現など、多くの複雑なタスクに対する広範なサポートを備えています。 .NET Framework の機能を使用すると、何千もの事前構築済みのクラスとルーチンにアクセスできます。 これらのクラスは、任意のストアド プロシージャ、トリガー、またはユーザー定義関数から簡単にアクセスできます。 基底クラス ライブラリ (BCL) には、文字列操作、高度な数学演算、ファイル アクセス、暗号化などの機能を提供するクラスが含まれています。

マネージド コードの利点の 1 つはタイプ セーフであることです。つまり、コードから各データ型へのアクセスは、正しく定義された許容される方法に限られます。 CLR は、マネージド コードが実行される前に、そのコードが安全であることを確認します。 たとえば、コードは、以前に書き込まれていないメモリが読み取られないことを確認するためにチェックされます。 CLR は、コードがアンマネージ メモリを操作しないようにするのにも役立ちます。

CLR 統合を使用すると、パフォーマンスが向上する可能性が高くなります。 詳細については、「 CLR 統合アーキテクチャのパフォーマンスを参照してください。

Transact-SQL とマネージド コードのどちらかを選択する

ストアド プロシージャ、トリガー、およびユーザー定義関数を記述するときは、従来の Transact-SQL を使用するか、Visual Basic や C# などの .NET Framework 言語を使用するかを決定する必要があります。 コードがほとんどの場合、手続き型ロジックをほとんどまたはまったく使用しないデータ アクセスを実行する場合は、Transact-SQL を使用します。 複雑なロジックで CPU を集中的に使用する関数やプロシージャ、または .NET Framework の BCL を使用する場合は、マネージド コードを使用します。

サーバーでの実行とクライアントでの実行の選択

Transact-SQL とマネージド コードのどちらを使用するかに関する決定のもう 1 つの要因は、コードを配置する場所、サーバー コンピューター、またはクライアント コンピューターです。 Transact-SQL とマネージド コードの両方をサーバー上で実行できます。 サーバー側でコードを実行すると、コードとデータが近くにあるため、サーバーの処理能力を活用できます。 一方、データベース サーバーにプロセッサを集中的に使用するタスクを配置しないことをお勧めします。 現在のほとんどのクライアント コンピューターは強力であり、可能な限り多くのコードをクライアントに配置することで、この処理能力を活用したい場合があります。 マネージ コードはクライアント コンピューターで実行できますが、Transact-SQL では実行できません。

拡張ストアド プロシージャとマネージド コードのどちらかを選択する

拡張ストアド プロシージャは、Transact-SQL ストアド プロシージャでは不可能な機能を実行するように構築できます。 ただし、拡張ストアド プロシージャは SQL Server プロセスの整合性を損なう可能性があります。一方、型セーフであることが確認されたマネージド コードは侵害できません。 さらに、メモリ管理、スレッドとファイバーのスケジュール設定、および同期サービスは、CLR と SQL Server のマネージド コードの間でより深く統合されます。 CLR 統合を使用すると、Transact-SQL では実行できないタスクを実行するために必要なストアド プロシージャを記述する拡張ストアド プロシージャよりも安全な方法を使用できます。 CLR 統合と拡張ストアド プロシージャの詳細については、「 CLR 統合アーキテクチャのパフォーマンスを参照してください。

関連するコンテンツ

• .NET framework のインストール ガイド
• CLR 統合アーキテクチャ - CLR でホストされる環境
• CLR データベース オブジェクトからのデータ アクセス
• CLR 統合の概要
• SQL Server 言語拡張で .NET ランタイムを呼び出す方法