更新すべきではない列の更新を明示的に拒否する必要がありますか？

私は非常に安全な環境で作業することに慣れているため、非常に細かい粒度で権限を設計します。私が通常行うことの1つは、更新されるべきではない列DENYに対する機能を明示的にユーザーに提供するUPDATEことです。

例えば：

create table dbo.something (
    created_by varchar(50) not null,
    created_on datetimeoffset not null
);

これらの2つの列は、値が設定されたら変更しないでください。したがって、私は明示的にそれらDENYのUPDATE許可をします。

最近、チームミーティング中、開発者は、「何らかの理由で値を更新する必要がある場合」に、フィールドが更新されないことを保証するロジックをデータベース層ではなくアプリケーション層に含めるべきであると指摘しました。私にとっては、典型的な開発者のメンタリティのように聞こえます（私は知っています、私は以前は1人でした！）

私は会社のシニアアーキテクトであり、アプリを機能させるために必要な最小限の特権の原則に常に取り組んできました。すべての許可は定期的に監査されます。

このシナリオのベストプラクティスは何ですか？

引数は意味をなしません。私は常に、コントロールと制約を可能な限りデータに近づけたいです。アプリケーション層に配置するということは、アプリケーション層を使用している人にのみ影響を与えることを意味し、コードにバグがなく、それらのコードパスのセキュリティが防弾であると想定しています。これらは大きな前提です。

絶対に更新する必要がある場合は、明示的なの影響を受けていない人がそれを行うDENYか、その人を一時的に影響を受けない役割に移動するか、DENY一時的に削除することができます。これらは、DBAとして、簡単に監査をセットアップできるものです。アプリで？そんなにない。

これの技術的な側面については、@ Aaronに完全に同意します。

それを超えて、ベストプラクティスに関して：

1. データを保護するのはDBAの仕事/責任であるため、デフォルトのアプローチでは、DBAが適切であると判断し、変更を行うための堅実なビジネスケースが必要です。想定される将来の可能性、ある程度可能性のある特定の条件、その後にブレーンストーミングされ、後で確認され、その後十分に変更された後、または変更される可能性があります-実際に発生した理由（つまり、「何らかの理由で」）は、特にトピックが会社の標準/慣行を変更している場合は、正当化が少し薄弱に思えます。

2. 決して変更すべきでないものに変更を加えたい人を決して信用しないでください;-)（彼らがなぜそうしたいのかさえ知らない場合はなおさらです）。

3. 開発者に、そのようなロジックをアプリコードに追加してこれらの更新を防ぐことを歓迎することを伝えます。しかし、また、あなたはDENY。もしその日が来たら（そしてではないかもしれないおそらく、誰かがこれらの列のいずれかを更新しようとしてエラーを取得することはありません。その後DENY、を削除するかどうかについて議論することができます。最初の場所。

   ポイント：人々が時間を費やすものを推進する実際のビジネスケースがあるはずです。時間は非常に需要がありますが、不足しているため、あなた（および他のすべての人）は、誰かの意見に基づいてシステムを変更するよりも重要なことをしなければなりません。常にさまざまな意見があります（スペースかタブか、誰でも？）。その開発者が去り、更新可能なフィールドに強く反対する開発者に取って代わられる場合、これを何度も変更することができます。これを要求している顧客（またはそれを必要とするもの）がなく、具体的なメリットがない場合（技術的な負債をクリーンアップするなど、ROIを表示するのが困難であるが、その時間が費やされて長期的には実際のコスト削減につながらない可能性はわずかです）、次に、理想主義が変更する必要があると言っている場合でも、リクエストを閉じるか、バックログに低い優先度で配置します（これはそのようなケースではありませんが、そうだと思う人のために言及されています）。理想主義は会話には最適ですが、企業は家賃、光熱費、従業員、税金などを理想的に支払うことはできません。

4. @ jpmc26は通信の必要性については正しいですが、通信の必要性については正確ではありません。はい、他の人が要求していることに耳を傾け、その理由を理解するよう努める必要があります。

   ただし、データベースはアプリケーションに従属的ではなく、データベースの専門家（管理者、エンジニア、会社が使用する名前は何でも）は開発者に従属的ではありません（その答えに暗示されているようです）。開発者のために働くのではなく、会社のために働くのです。彼らと同じです。これはチームの努力であり、あなたは自分の仕事をすることを許してはいけません。とはいえ、コンピューターの種類は人間間のコミュニケーションスキルでは（一般に）知られていないので、他の人があなたを理解していること、あなたの推論が何であるか、あなたの責任が何であるか、そしてこれらが実際にどのように機能するかを本当に確認する必要があります。

   かなりの誤解、誤報、および知識の欠如がそこにあるので、私はその最後の部分を入れました（このページのどこかでさえ）。たとえば、すべてのルールはビジネスルールであるという考えがあります。データルールとビジネスルールには区別があることを説明する必要があります（@Aaronは質問のコメントでこれを「ワークフロー制約とデータ制約」と呼びます）、そしてほとんどのデータは自然にアプリケーションに属しますが、一部のデータ実際にはデータモデルに属します。DBAは、アプリケーションデータの制約方法を開発者に指示する必要がありますか？もちろん違います。アプリケーションデータができることを提供するのが私たちの仕事です制約されます。アプリケーションデータに関連するビジネスルールの違反が害を及ぼす可能性があり、アプリがデータを操作する100％の唯一の方法ではない場合、おそらくチェック制約が本当に役立つ可能性があります（そして、それらを変更または削除することは難しくありません） ）。

   しかし、他の方向から来た開発者は、データモデルデータ（メタデータ）の処理方法を指示するべきではありません。これには、監査フィールド（created_on/ created_by列など）とPK / FK列が含まれます（これらの値は内部でのみ知られ、顧客には提供されないことになっています）。このデータは、アプリが顧客について保存するものではありません（アプリが値を参照し、IDなどで使用する場合でも）、データモデルはアプリのデータについて保存します。

   したがって、データルールを使用してデータモデルデータを保護することは理にかなっています。また、そうすることは、アプリケーションデータに制約または制限を追加し始めることを意味するものではありません。しかし、この区別が理解されない場合、真に生産的な方法で会話を進めることは困難です。

そう：

1. はい、DENY監査コラムの明示的なアイデアが好きで、過去に働いた場所でも同じことを提案しました。

2. 逸話的には、おそらく2000年に外部キーを追加し始めたときに、リード開発者（非常に良い開発者）と非常によく似た会話をしました。彼は、それは不必要なオーバーエンジニアリング/理想主義（そのようなもの、その会話から17年が経過している）であり、パフォーマンスヒットの価値はないと主張しました（非常に真剣に）。彼は、関連データのクリーンアップをアプリ層で処理する必要があることを非常に明確にしました。（はい、私はFKを追加しました。なぜなら彼は、彼のコードが必然的に作成する孤立したデータをクリーンアップする人ではなかったからです）

   数年後、彼はその議論をして謝罪した;-)

これはおそらくXYの問題です。開発者はおそらく、のような本当に一定のフィールドへの更新をブロックすることに特に関心はありませんcreated_on。この特定の例は、非常に控えめな制約です。

開発者はおそらく、DBAチーム（あなたを含む）が非常に多くの、または非常に複雑な制限を追加して、効果的に仕事をする能力を妨げようとしていること、または異常が発生した場合、または何かが変更された場合、DBAチームが変更に抵抗し、開発者チームの進歩を妨げることになります。これは比較的合理的な懸念事項です。官僚制度と必要な変更に影響を与える能力の喪失は実際の出来事であり、多すぎるまたは複雑な制約をエンコードすると、パフォーマンスや要件の変更に対応する能力に悪影響を与える可能性があります。

開発者は、これが彼らの懸念の性質であることにさえ気付かないかもしれません。彼らはデータベースの自由な統治に慣れている可能性が高く、そのレベルの自由を放棄することは困難です。したがって、必要なことを実行する能力を失うことに対する彼らの懸念は、曖昧で不明確なものになります。

そのため、これらの不安を和らげるためにすべきことがいくつかあります。

1. 開発者と頻繁に通信します。ビルドしようとしている機能のニーズを理解し、変更が発生したときに応答することを確認してください。彼らが言わなければならないことを聞いて、あなたの懸念と彼らの懸念のバランスをとる解決策を見つけるために一生懸命働きます。正当なニーズがある場合は、喜んで曲がります。あなたが彼らがソフトウェアを構築する上で味方であることを彼らが知っていることを確認してください。
2. 制限をかけることに注意してください。制限は、整合性とセキュリティを提供することを意図したものであっても、変更への適応や予期せぬ状況への対処を難しくする可能性があります。したがって、追加する各制限には、コストを節約する可能性があるのと同様にコストが関連付けられる可能性が高いことを理解してください（実質的にマイナス面のない主キーと外部キーを除く）。あなたが課す制限が本当に必要か有益であると確信してください。
3. あなたがこれをしている兆候は見当たりませんが、他の読者にはそれについて言及したいと思います。あなたやあなたのチームの責任としてデータやデータベースを見ないでください。データは会社全体の資産です。データベース（データベース）と、スクリプト、ツール、またはアプリケーションを作成、更新、取得するためのシステムがなければ、データは価値がありません。誰もがこの資産を使用する必要があるため、データは全員の責任です。データベース自体は、データから価値を得るための一部にすぎません。

矛盾する声明があります

• 更新されるべきではない列
• 何らかの理由で値を更新する必要があります

最初に口述するのは本当にあなた次第ですか？

アプリが値を更新する必要がないことを証明せずにアプリを動作させるために、最小限の特権をスローします。

データの整合性の責任者は誰ですか？

SQL制約を使用すると、データの整合性を保証できますか？多くの場合、データベースでできることを超えたビジネスルールがあるため、できません。

VendorID は決して変更されませんが、2つのベンダーがマージされた場合はどうなりますか。絶対とは絶対言うな。

アプリチームがデータを汚染し、その権限が必要だと言った場合、それは彼らにあります。アプリチームがあなたのために働くなら、あなたは口述することができます。

適切な質問は、アプリがデータを更新すべきかどうかです。