プレビュー機能として使用できるようになりました。いうことで少しまとめてみたいと思います。Previewを参照していただければと。実装がされていません。使用しいている場合には利用することができません。Database)を使用してテーブルからのデータ取得に対してフィルターを設定するイメージになるかと思います。作成の流れは以下のようになります。クエリのベースは冒頭で紹介したリンク先のものを使用しています。使用するためには最初にセキュリティ述語関数を作成します。上にテストデータベースとテスト用のテーブルを作成します。場合はクラスター化インデックスなしでテーブルが作成できます。5);次にセキュリティ述語関数を作成します。'Manager';セキュリティ述語関数はテーブルを返すテーブル値関数の必要がありますので、検索結果を返すようにしています。句にはフィルターの条件を設定する必要があります。次にセキュリティポリシーを作成します。かけるかフィルターにはどのテーブル値関数を使用するかテーブルのどの項目を使用してフィルターをかけるかを設定します。「dbo.Sales」テーブルに「dbo.fn_securitypredicate」テーブル値関数を使用して「SalesRep」を使用してフィルターをかけるということになります。関数の結果が「Manager」の場合はすべてそれ以外の場合は「SalesRep」が「ユーザー名」のレコードのみが検索されるようになります。行レベルセキュリティは管理者アカウントでも同様に動作が行われます。そのため、セキュリティポリシーが設定されているテーブルでは管理者が全件取得をしようとした場合も以下のような結果になります。それではデータベースにユーザーを作成して試してみたいと思います。実行ユーザーを切り替えながら実行した結果がこちらになります。場合は、「SalesRep」が自分のユーザーのもの、「Manager」の場合はすべてのレコードが検索されていることが確認できます。この動作は「SELECT」だけでなく、「UPDATE」「DELETE」にも適用されます。SalesREVERT;実行の結果がこちらになります。実施しているため、操作ができずにデータが変更されていないため、実行前後で結果が変わっていない形になります。このセキュリティ機能については「INSERT」については利用することができません。できてしまうためこの辺についてはトリガーで生業が必要になってくるかと。することもできますので、一時的に無効にすることも可能です。Sales;この動作ですが、フィルターによって実装されているようです。データサイズが大きくなってきた場合には処理のオーバーヘッドが気になってきますね。検索した結果を返す際にフィルターをしているようですので、インデックス有無の影響はないのかな。SalesREVERT;行レベルのセキュリティは今まではビューで実装することがあったかと思いますが、関数ベースでテーブルに対して透過的に設定をすることができるのは面白いですね。チューニング等をメインにしていますが、本ブログで情報発信している内容に関することでしたら対応できます。お仕事のご相談がありましたらTwitterfacebookやブログのコメントでご連絡いただけると幸いです。ブログにコメント頂いた内容は私が承認しない限り表示されません。受賞させていただきました。本ブログの内容は個人的に検証したものとなり、検証結果を含め記載している内容を保証するものではありません。体験記の連載をさせていただきました。最後まで飲み切れず...。