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

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

#1 楼

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

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

#2 楼

对于此技术方面，我完全同意@Aaron。

我要说的是关于最佳做法的信息：


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

告诉开发人员，欢迎他们向应用程序代码添加此类逻辑以防止这些更新。但是，同样，您也不会删除DENY。如果/当一天到来时（可能不会），有人在尝试更新这些列之一时出错，那么您可以讨论是否要删除DENY，这将需要，为什么有人会首先更新该值的确凿证据。

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


@ jpmc26对于沟通的需求是正确的，但对于沟通的需求却不是完全正确的需要沟通。是的，您应该听取别人的要求，并设法理解他们的推理，其中包括如果您不清楚任何内容，请提问。但是，数据库不能从属于应用程序，数据库专业人员（管理员，工程师，无论您的公司使用什么名称）都不能从属于开发人员（在该答案中似乎暗示了这一点）。您不像开发人员那样为开发人员工作，而是为公司工作。这是团队的努力，您不应该原谅您的工作。也就是说，我们的计算机类型并不是（通常）以我们的人际交流技能而闻名，因此，您确实需要确保其他人理解您，您的推理是什么，您的责任是什么以及这些东西是如何工作的。

之所以放在最后一部分是因为那里存在高度的误解，错误的信息和缺乏知识的知识（甚至在此页面的某些地方）。例如，似乎有一种观念，即所有规则都是业务规则。我们需要解释数据规则和业务规则之间存在区别（@Aaron在对该问题的评论中将其称为“工作流约束与数据约束”），并且尽管大多数数据自然属于应用程序，但某些数据实际上属于数据模型。 DBA是否应该指示开发人员如何限制应用程序数据？当然不是。提供如何限制应用程序数据是我们的工作。如果违反与应用程序数据相关的业务规则可能会造成伤害，并且应用程序不是操作数据的100％唯一方法，那么检查约束可能确实会有所帮助（并且更改或删除它们并不难） ）。

但是，从另一个方向来看，开发人员不应规定如何处理数据模型数据（即元数据）。这包括审核字段（例如created_on / created_by列）和PK / FK列（这些值仅在内部已知，并且不提供给客户）。此数据不是应用程序存储的有关客户的内容（即使应用程序可以看到甚至使用ID（例如ID）使用它们），也正是数据模型存储的有关应用程序数据的内容。

因此，使用数据规则来保护数据模型数据是有意义的。这样做并不意味着您将开始对应用程序数据添加约束或限制。但是，如果不理解这种区别，将很难以一种真正有效的方式推进对话。


所以：


是的，我喜欢在审计列上使用明确的DENY的想法，并且在我过去工作过的地方也提出了相同的建议。 （非常好），也许是在2000年，当我开始添加外键时。他（非常认真地）辩称，这是不必要的过度设计/理想主义（类似的话，自那次谈话以来已经有17年了），并且不值得影响性能。他非常清楚，清理相关数据应在应用程序层中进行。 （是的，我确实添加了FK，因为他不会成为清理他的代码将不可避免地创建的孤立数据的人）

几年后，他为提出该论点表示歉意;-)

#3 楼

这可能是一个XY问题。开发人员可能并不特别关心阻止对像created_on这样的真正恒定字段的更新。这个特定的示例是一个非常适度的约束。

开发人员可能会担心DBA团队（包括您在内）打算添加太多或如此复杂的限制，从而开始阻碍他们有效工作的能力。 ，或者出现异常情况或发生更改时，DBA团队将抵制这些更改并阻碍开发人员团队取得进步的能力。这是一个相对合理的问题。官僚机构和失去影响所需变更的能力是真实的情况，编码过多或复杂的约束可能会对性能以及对需求变更的响应能力产生负面影响。

开发人员可能不会甚至意识到这是他们关注的本质。他们可能习惯于自由支配数据库，而放弃那种自由度是困难的，尤其是如果您知道自己从未滥用过它。
因此，他们担心失去做自己需要做的事情的能力的感觉很模糊且定义不清。

因此，您应该采取一些措施来减轻这些恐惧：


与开发人员进行大量交流。确保了解他们正在尝试构建的功能的需求，并确保在更改发生时能够及时响应。听取他们的意见，并努力寻找一种解决方案，以平衡他们与您的担忧。当他们有合理的需求时愿意弯曲。确保他们知道您是他们构建软件的盟友。
在设置限制时要谨慎。限制，即使是旨在提供完整性和安全性的限制，也可能使其更难以适应变化或应对不可预见的情况。因此，请理解，您添加的每个限制都有与其相关的成本，也有可能节省了成本（主键和外键可能没有例外，但实际上没有缺点）。要确信您施加的限制确实是必要的或有益的。
我看不到您在执行此操作的任何迹象，但我想向其他读者提及：不要查看数据或数据库作为您或您团队的责任。数据是整个公司的资产。如果没有系统来存储它（数据库）以及没有脚本，工具或应用程序来创建，更新和获取它，那么数据就一文不值。因为每个人都必须使用此资产，所以数据是每个人的责任。数据库本身只是从数据中获取价值的一部分。

#4 楼

您有冲突的语句


永远不应该更新的列
由于某些原因它们需要更新值

这真的取决于您决定第一？

如果没有证明应用程序永远不需要更新值，您将获得最少的特权以使该应用程序正常工作。

谁负责数据完整性？

使用SQL约束可以保证数据完整性吗？不，您不能这样做，因为通常存在超出数据库所不能提供的业务规则。

VendorID永远不会改变，但是如果两个供应商合并，该怎么办。永远不要说永不。

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

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