CLR 統合の概要

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

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

マネージド コードでは、コード アクセス セキュリティ (CAS) を使用して、アセンブリが特定の操作を実行できないようにします。 SQL Server では、CAS を使用してマネージド コードをセキュリティで保護し、オペレーティング システムまたはデータベース サーバーの侵害を防ぎます。

CLR 統合の利点

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

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

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

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

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

Transact-SQL とマネージド コードの選択

ストアド プロシージャ、トリガー、およびユーザー定義関数を記述する場合、従来の Transact-SQL を使用するか、Visual Basic .NET や Visual 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 統合の概要