我应该明确拒绝不应该更新的列吗？

我习惯在非常安全的环境中工作，因此我将权限设计为非常精细。我通常要做的一件事是显式地DENY使用UPDATE不应该更新的列的功能。

例如：

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

设置值后，永远不要更改这两列。因此，我明确DENY了UPDATE他们的权限。

最近，在一个团队会议中，开发人员提出了一个观点，即确保字段永远不会更新的逻辑应该包含在应用程序层而不是数据库层中，以防“他们出于某种原因需要更新值”。对我来说，这听起来像是典型的开发者心态（我知道，我曾经是一个！）

我是公司的高级架构师，我一直致力于使应用程序正常运行所需的最少特权。所有权限都会定期审核。

在这种情况下，最佳做法是什么？

这种说法没有道理。我一直希望控件和约束条件尽可能接近数据。将其放在应用程序层中意味着它仅会影响使用应用程序层的人员，并且还假定该代码将是无错误的，并且这些代码路径周围的安全性将是防弹的。这些是很大的假设。

如果绝对需要更新它们，那么可以由不受显式影响的人来完成DENY，或者可以将该人暂时移入不受影响的角色，或者DENY可以将其暂时删除。作为DBA，这些事情对于您来说很容易进行审核。在应用程式中？没那么多。

我在技术方面完全同意@Aaron。

除此之外，关于最佳做法：

1. 鉴于保护数据是DBA的工作/职责，默认的方法应该是按照DBA的认为做到这一点，并且需要有扎实的业务案例进行更改。一种假设的潜在潜在某种给定的条件，将在以后被脑力激荡并得到确认，但是可能以后会改变，甚至永远不会改变-实际发生的原因（即“出于某种原因”）似乎有些不足，特别是当主题正在更改公司标准/惯例时。

2. 永远不要信任想要对永远不应该改变的事物进行更改的人；-），（即使他们甚至不知道为什么要改变，更是如此）。

3. 告诉开发人员欢迎他们向应用程序代码中添加此类逻辑，以防止这些更新。但是，同样，您也不会删除DENY。如果/当一天到来（和它也许不会可能不会），有人在尝试更新这些列之一时出错，然后您可以讨论是否要删除DENY，这将需要确实可靠的理由来说明为什么有人要在列中更新该值第一名。

   重点是：应该有一个真实的商业案例来驱动人们花费的时间。时间需求旺盛，但供应短缺，因此，您（和其他所有人）要做的事情要比根据某人的意见更改系统更重要。总是会有各种各样的意见（空格还是制表符，有人吗？），如果该开发人员离开并被强烈反对那些可更新字段的开发人员所取代，那么您可能会花费数年的时间来反复更改此意见。如果没有客户要求这样做（或需要它的东西），并且没有明显的收益（甚至是延迟收益，例如清理技术债务，这很难证明投资回报率，但是鉴于从长远来看，花费时间而不导致实际成本节省的机会微乎其微），然后要么关闭请求，要么将请求低优先级地放在待办事项上，即使在理想主义说应该更改它的情况下（这不是其中一种，但是为那些认为是这种情况而提到）。理想主义非常适合进行对话，但是公司不能用理想来支付房租，公用事业，员工，税金等。

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 永远不应更改，但是如果两个供应商合并，该怎么办。永不说永不。

如果应用团队污染了数据，并且他们说他们需要该权限，那么该权限就在他们身上。如果应用团队为您工作，那么您可以决定。

合适的问题是应用程序是否应该更新数据。