MSSQL 2016で行レベルのセキュリティで保護されたテーブルに新しい列を追加する場合は、SQL Serverのデータツールを使用してデータベースを公開しようとすると、RLSで保護さMSSQLテーブル（SSDT）

Question

を変更、私は次のエラーを取得する：

現在の操作が、それはオプション/ pは、この操作を使用SqlPackage.exeを許可するポリシーYで有効になって行レベルのセキュリティを持っているため、表X.データの動きのデータの動きは、このテーブル上で実行することができない原因になります。AllowUnsafeRowLevelSecurityDataMovement

テーブルを再作成したいと思うので、 e配備ユーザーは、RLS述部によるデータへのアクセスを許可されていません。しかし、私はこれについてのドキュメントを見つけることができません。

さらに重要なのは、このような展開シナリオを処理するためのベストプラクティスは何ですか？

Answer 1

このシナリオの2つの側面がある：

• なぜカラムの添加はデータモーション操作が発生する原因となっていますか？
• 行レベルセキュリティによって導入される危険性は何ですか？

最小化/データの動きを必要とすべきではない、新しい列を追加する一般的にはデータの動き

を回避することができます。テーブル定義の末尾に追加すると、これはALTER TABLE ADD COLUMN操作で行うことができ、SSDTはこれを行うのに十分スマートです。ただし、テーブルの中央に追加した場合、デフォルトの動作は完全なデータ移動を行い、大きなテーブルでは非常にコストがかかる場合があります。これを避けるには：

• 可能であれば、最後に列を追加してください。
• これが不可能な場合、最近のバージョンのSSDT & SqlPackageには、末尾に追加されたかのように列の追加をテーブルの中央で処理するIgnoreColumnOrderフラグがあります。これは、（例えば、スキーマがあまりにもこのセットを持っている必要があります比較したり、テーブルのソースプロジェクト&データベースのバージョンとの違いを紹介します）いくつかの合併症を引き起こすが、展開中の不要なデータの移動を避けるために、通常は価値があることができ

行レベルセキュリティ（RLS）+データの操作の処理

データの移動を引き起こす変更を実際に行う必要がある場合、RLSのリスクはユーザーがテーブルのすべての行にアクセスできないことです。データモーションはテンポラリテーブルにデータをコピーした後、オリジナルの名前を変更すると、ユーザが見ることができなかった行が失われます。

解決策は、/p:AllowUnsafeRowLevelSecurityDataMovementフラグを設定することですが、ユーザーが行レベルのフィルタリングスキームに含まれていないことを確認することです。良い方法は、制限された権限（例えば、あなたのアプリケーションの役割）を持つユーザーにしかそれらのスキームを適用するのではなく、展開時により大きな権限を持つ役割（管理者の役割）を使用することです。これを行うと安全に配備できますが、フラグは少なくともこれについて警告し、偶発的なデータ消失を防ぎます。