問題タブ [row-level-security]

出力を期待します:

のみを表示する必要(2,'{"section2"}')がありますが、すべてを表示します。

がsub_section入力されるsection_tableと、対応するセクションを見つけて と交差しuser_table、交差の値が null でなくなると、対応する の値を返す必要があります user_table。

なぜ正しい期待結果が表示されないのか混乱しています。

SQL Server 2016 を使用して行レベル セキュリティを実装しました。複雑なセットアップが失敗したと思いますが、セキュリティ要件は複雑です。

これは、データ ウェアハウスのコンテキストにあります。基本的なファクト テーブルとディメンション テーブルがあります。次の設定で、ディメンション テーブルの 1 つに行レベル セキュリティを適用しました。

表 1 : dimDataSources (標準の物理テーブル)
表 2 : dimDataSources_Secured (メモリ最適化テーブル)

dimDataSources_Securedネイティブ コンパイル機能を使用する (インメモリ) でセキュリティ ポリシーを作成しました。この関数は、レコードを読み取ることができるルックアップ値と Active Directory グループを含む別のメモリ最適化テーブルを読み取ります。この関数は、is_member()関数を使用して、グループに許可されているすべてのレコードに対して 1 を返します。

そのため、コンテキストは少し複雑に見えますが、これまでのところ機能しています。しかし...今、これをファクトテーブルとの接続で使用するようになり、パフォーマンスが低下します。ここでは、行レベルのセキュリティをファクト テーブルに直接適用するのではなく、ディメンション テーブルのみに適用します。

だから私の問題は、これを実行する場合です：

2 秒としましょう。

保護されたテーブル (またはビュー) で結合を使用して同じクエリを実行すると、5 ～ 6 倍の時間がかかります。

これにより、AD グループに基づいてアクセスできるソースのみが取得されます。実行計画が変更されると、ファクト テーブルのデータをすばやく取得するように見えますが、インメモリ テーブルでネストされたループ ルックアップを実行して、許可されたレコードを取得します。

その動作は、フィルター述語関数の使用によって引き起こされますか? 行レベル セキュリティを使用して良い経験または悪い経験をした人はいますか? 製品化するのに十分なほど成熟していますか? データ ウェアハウス (つまり、大量のデータの処理) に適していますか?

小説を書かずに、実際の機能とクエリをさらに詳しく説明することは困難です。私は主にガイドラインや代替案を探しています。