“惩罚”开发人员或自动修复？触发与约束

Question

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

以下是一些想法：

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

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

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

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

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

Answer 1

这取决于为什么列需要大写，但一般情况下我会选择约束。

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

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

Answer 2

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

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

Answer 3

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

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

添加不区分大小写的索引可能是更好的解决方案（参见Database Case Insensitive Index）

Answer 4

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

Answer 5

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

Answer 6

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