更新してはならない列に対する更新を明示的に拒否する必要がありますか？
私は非常に安全な環境での作業に慣れているので、許可を非常に細かい単位で設計します。私が通常行うことの1つは、更新する必要のない列をDENY列に明示的にUPDATEユーザーに示すことです。
例えば：
create table dbo.something (
created_by varchar(50) not null,
created_on datetimeoffset not null
);
値を設定した後は、これらの2つの列を変更しないでください。したがって、明示的にDENYUPDATE権限を付与します。
最近、チームミーティング中に開発者は、フィールドが更新されないことを保証するロジックは、「何らかの理由で値を更新する必要がある」場合に、データベースレイヤーではなく、アプリケーションレイヤー内に含める必要があると指摘しました。私には典型的な開発のように聞こえます（私は知っています、私は以前は1つでした！）
私は会社のシニアアーキテクトであり、アプリを動作させるために必要な最小限の特権の原則に常に取り組んできました。すべての権限は定期的に監査されます。
このシナリオのベストプラクティスは何ですか？
議論は意味をなさない。私は常にコントロールと制約を可能な限りデータに近づけたいです。それをアプリケーション層に配置することは、人々にのみ影響を与えることを意味しますsingアプリケーション層、そしてまた仮定コードにはバグがなく、それらのコードパスに関するセキュリティは防弾。それらは大きな仮定です。
更新が絶対に必要な場合は、明示的なDENYの影響を受けない人が行うか、影響を受けないロールに一時的に移動するか、DENY一時的に削除されます。これらは、DBAが簡単に監査を設定できるものです。アプリ内？それほどではありません。
これの技術的な側面については、@ Aaronに完全に同意します。
それを超えて、ベストプラクティスに関して：
データを保護するのはDBAの仕事/責任であることを考えると、デフォルトのアプローチは、DBAが適切と考えるようにそれを行うことであり、変更を行うための確かなビジネスケースを必要とします。架空の将来の可能性-ある程度可能性のある特定の条件-その意志のブレインストーム-後で-確認された後-しかし、後で変化する可能性があるか、または可能性がない-実際に起こった理由（つまり、「何らかの理由で」）は、特にトピックが会社の標準や慣行を変更している場合、正当化の少し薄弱なようです。
決して変更してはならないものに変更を加えたい人を信頼しないでください;-)（さらに、なぜ変更したいのかさえわからない場合はなおさらです）。
それらの更新を防ぐために、そのようなロジックをアプリコードに追加することを歓迎することを開発者に伝えます。ただし、
DENYを削除しないことにも注意してください。いつ/その日が来ると（そしてそれはではないかもしれないこれらの列の1つを更新しようとしたときにエラーが発生することはおそらくありませんthenDENYを削除するかどうかについて議論することができます。 、そもそも誰かがその値を更新する理由をしっかりと正当化する。要点：人々が時間を費やしているものを推進する実際のビジネスケースがあるべきです。時間は需要が多いが供給が不足しているため、誰か（そして他の誰も）は誰かの意見に基づいてシステムを変更するよりも重要なことをしています。常にさまざまな意見があり（スペースとタブ、だれですか？）、その開発者が辞任して、更新可能なフィールドに強く反対する人に置き換えられた場合、これを何度も変更することができます。顧客がこれ（またはそれを必要とするもの）を要求しておらず、具体的なメリットがない場合（ROIを示すのは難しいが、技術的負債のクリーンアップなどの遅れたメリットであっても）、その時間が費やされた結果、長期的には実際のコスト削減につながらない可能性はごくわずかです）、理想主義が変更すべきであると言っている場合でも、リクエストを閉じるか、低い優先度でバックログに入れます（これはそれらのケースの1つではありませんが、そうであると考える人のために言及されています）。理想主義は会話に最適ですが、企業は理想的に家賃、公共料金、従業員、税金などを支払うことはできません。
@ jpmc26は通信の必要性については正しいですが、通信する必要があるものに関しては正確ではありません。はい、あなたは他の人が要求していることに耳を傾け、彼らの推論を理解するように努めるべきです。
ただし、データベースはアプリケーションに対応しておらず、データベースの専門家（管理者、エンジニア、会社が使用している名前は何でも）は開発者に対応していません（その回答で暗示されているようです）。あなたは開発者のために働くのではなく、会社と同じように働きます。これはチームの努力であり、あなたの仕事をすることの許しを請うべきではありません。とは言っても、私たちのコンピュータータイプは人間同士のコミュニケーションスキルで（一般に）知られていません。そのため、他の人にあなた、あなたの推論は何か、あなたの責任は何かを理解させる必要があります。 、そしてこれが実際にどのように機能するか。
かなりの誤解、誤った情報、そしてそこにある知識の欠如があるので、私はその最後の部分を入れました（このページのここでさえも）。たとえば、すべてのルールはビジネスルールであるという考え方があるようです。データルールとビジネスルールの違いがあることを説明する必要があります（@Aaronは、質問のコメントでこれを「ワークフロー制約vsデータ制約」と呼んでいます）andほとんどのデータは自然にアプリケーションに属し、一部のデータは実際にはデータモデルに属しています。 DBAは、アプリケーションデータwillをどのように制約するかを開発者に指示する必要がありますか？もちろん違います。アプリケーションデータcanをどのように制約するかを提供するのが私たちの仕事です。アプリケーションデータに関連するビジネスルールの違反により害が生じる可能性があり、アプリが100％のみの方法でデータを操作していない場合、おそらくチェック制約が実際に役立つ可能性があります（そして、変更または削除するのは難しくありません）。
しかし、他の方向から来て、開発者はデータモデルデータ（つまり、メタデータ）の処理方法を指示すべきではありません。これには、監査フィールド（
created_on/created_by列など）とPK/FK列が含まれます（これらの値は内部でのみ認識され、顧客には提供されません）。このデータは、アプリが顧客について保存するものではなく（アプリが値を表示でき、IDを使用するなどして使用する場合でも）、データモデルがアプリのデータについて保存するものです。したがって、データルールを使用してデータモデルデータを保護することは理にかなっています。また、そうすることで、アプリケーションデータに制約または制限を追加しようとしていることを意味するものではありません。しかし、この区別が理解されていないと、真に生産的な方法で会話を進めることが困難になります。
そう：
- はい、私は監査列の明示的な
DENYのアイデアが好きで、私が過去に働いた場所でも同じことを提案しました。 事例として、おそらく2000年に外部キーの追加を開始したときに、リード開発者（非常に優れた開発者）と非常によく似た会話をしました。彼は、不必要な過剰設計/理想主義（そのような何か、その会話から17年が経過している）は不要であり、パフォーマンスに影響を与える価値がないと（真剣に）主張しました。彼は、関連データのクリーンアップはアプリレイヤーで処理する必要があることを明確に示しました。 （はい、彼のコードが必然的に作成する孤立したデータをクリーンアップするのは彼ではなかったので、私はFKを追加しました）
数年後、彼はその議論をしたことを謝罪した;-)
これはおそらくXY問題です。開発者は、created_onのような真に定数なフィールドへの更新をブロックすることに特に関心がないでしょう。この特定の例は、極端にささやかな制約です。
開発者はおそらく、DBAチーム（あなたを含む）が非常に多くのまたは非常に複雑な制限を追加することで、効果的に機能しなくなること、または通常とは異なることが起こったり何かが変化したりしたときに、DBAチームがそれを懸念している可能性があります。変更に抵抗し、開発者チームの進歩を妨げます。これは比較的合理的な懸念事項です。官僚主義と必要な変更に影響を与える能力を失うことは実際の出来事であり、あまりにも多くのまたは複雑な制約をエンコードすると、パフォーマンスと要件の変化に対応する能力に悪影響を与える可能性があります。
開発者は、これが彼らの懸念の性質であることさえ理解していないかもしれません。データベースを自由に支配することに慣れている可能性が高く、そのレベルの自由を放棄することは困難です。したがって、彼らが必要とすることを実行する能力を失うことに対する彼らの懸念の感覚は、あいまいで、はっきりしないかもしれません。
したがって、これらの恐怖を和らげるためにすべきことがいくつかあります。
- 開発者と頻繁にコミュニケーションします。彼らが構築しようとしている機能のニーズを理解していることを確認し、変更が生じたときに迅速に対応できるようにしてください。彼らが言わなければならないことを聞いて、彼らの懸念とあなたの懸念のバランスをとる解決策を見つけるために一生懸命働きます。彼らが正当なニーズを持っているときは、喜んで曲がってください。彼らがあなたがソフトウェアであることを知っていることを確認してくださいally.
- 制限を設けることに注意してください。完全性とセキュリティを提供するための制限であっても、制限は、変化への適応や予期しない状況への対処を困難にする可能性があります。したがって、追加する各制限は、コストを節約するのと同じくらいコストがかかる可能性が高いことを理解してください（実質的にマイナス面のない主キーと外部キーを除いて）。あなたが課す制限が本当に必要であるか、または有益であることを確信してください。
- あなたがこれをしているという兆候は見当たりませんが、他の読者のためにそれについて言及したいと思います。データまたはデータベースをyourまたはチームの責任。データは会社全体の資産です。データ（データベース）およびスクリプト、ツール、またはアプリケーションを作成、更新、およびフェッチするためのシステムがなければ、データは価値がありません。誰もがこの資産を使用する必要があるため、データはすべての人の責任です。データベース自体は、データから値を取得するための一部にすぎません。
矛盾する発言があります
- 更新してはならない列
- 何らかの理由で値を更新する必要がある
最初に口述するのはあなた次第ですか？
アプリが値を更新する必要がないことを証明せずにアプリを機能させるには、最小限の特権を投入します。
データの整合性は誰が担当しますか？
SQL制約を使用すると、データの整合性を保証できますか？いいえ、データベースでできることを超えるビジネスルールがよくあるため、できません。
VendorID should変更されることはありませんが、2つのベンダーが合併した場合はどうなりますか。絶対とは絶対言うな。
アプリチームがデータを汚染し、その権限が必要であると彼らが言った場合、それは彼らにあります。アプリチームがあなたのために働くなら、あなたは口述することができます。
適切な問題は、アプリがデータを更新する必要があるかどうかです。