“惩罚”开发者还是自动修复？触发与约束

Question

假设我有一个数据库列应始终为大写。

这里有一些想法：

1）创建列约束： col = UPPER(col)

2) 创建一个插入/更新前行触发器来设置： col = UPPER(col)

通常，对数据库数据的约束越多越好，并且触发器可能是神秘且糟糕的。假设编写代码的开发人员在同一个组织中，因此他们编写的代码可以由我们修改。

您会使用哪种方法？为什么？

它必须是大写的，因为相关数据实际上总是大写的（最初是由各种第三方打印的）。对于这个特定字段，大小写没有任何意义。

Answer 1

这取决于为什么该列需要大写，但一般来说我会选择约束。

我不喜欢当我将数据插入数据库时​​更改我的数据的东西。这意味着我写的内容和下次要读的内容不匹配。

如果文本已由用户输入，请考虑添加包含大写版本的额外列。这样，您始终显示用户输入的文本

Answer 2

在大多数情况下，我会说（1），因为正如你所指出的，触发器通常可能是坏/怪（虽然并非总是如此）。但是在处理字符串区分大小写时，我倾向于将其视为特殊情况，并始终在整个过程中的每一步都将其修复。我不确定我是否有任何具体的理由这样做，它只是“感觉”对。可能是因为在我工作的大多数环境中，从业务逻辑的角度来看， FoO 总是等于 foo 总是等于 FOO 。 / p>

此外，在这种情况下，开发人员说“FYI，所有字符串都以大写字母存储在服务器上”似乎没有什么负担。而不是每次忘记时拍他们的手腕。这并不是说“仅供参考，每次在数据库中插入价格时，都会增加销售税。”

Answer 3

这最好作为约束实现，它可以避免额外的负载，并做你想要的 - 强制数据采用你需要的格式。

我认为在数据库中强制转换是错误的方法，因为可以在数据库层中处理可以在不损失完整性的情况下进行转换的数据。如果案件无关紧要，那么就这样处理 - 并且约束有助于捕捉错误。

添加不区分大小写的索引可能是更好的解决方案（参见数据库案例不敏感索引）

Answer 4

或者增加自动化测试的覆盖范围，并避免生产服务器上的额外负载。

Answer 5

我还会考虑另一种方法 - 提供“表格API”。这允许开发人员只将值传递给存储过程（或其他），然后确保值在插入时为大写（根据您的示例）。我也会用一个约束来支持它（它可以帮助查询优化一件事）并删除表上的直接更改权限 - 如果你不相信开发人员大写所有插入，那么你不应该信任它们总是使用TAPI。

Answer 6

如果您可以在数据库副的列约束中执行某些操作，则通常首选它，因为它通常更快。如果您正在谈论通过应用程序执行，我不建议这样做。如果规则必须始终适用，则除了在数据库中之外，它永远不应该是任何地方。除了要编写代码的应用程序之外的其他内容可以更改数据库中的数据。数据完整性是数据库的责任，将代码保留在其所属的位置以避免出现问题。