目前,我们一直在致力于架构团队来定义数据库模型。一直困扰我的是我上司在审计领域的工作方面的建议。
他主张updated_at和updated_by字段为Nullable,并认为这些字段应该初始化为NULL,因为数据库条目还没有更新。
CREATE TABLE example_table (
...
created_at TIMESTAMP WITH TIME ZONE NOT NULL,
created_by VARCHAR(128) NOT NULL,
updated_at TIMESTAMP WITH TIME ZONE NULL,
updated_by VARCHAR(128) NULL
);此外,他指出,他从经验中了解到,最好还是把他们作为NULL,但不幸的是,他没有给我提供任何具体的例子。
我更倾向于将这些更新的字段设置为NOT NULL,因为:
created_at和updated_at字段具有相同的值,则可以很容易地确定记录是新的。以下是我要执行的内容:
CREATE TABLE example_table (
...
created_at TIMESTAMP WITH TIME ZONE NOT NULL,
created_by VARCHAR(128) NOT NULL,
updated_at TIMESTAMP WITH TIME ZONE NOT NULL,
updated_by VARCHAR(128) NOT NULL
);我在谷歌上搜索了一段时间,但找不到一篇文章指出选择是正确的,或者至少有一篇比另一篇更好。
所以我很好奇:我是不是遗漏了其他观点?哪种方法更好?
我的代码示例在SQL中,但我的问题也可能适用于其他数据库类型。
发布于 2018-05-25 18:31:11
一直困扰我的是我上司的建议..。
你有没有以可教的态度问你的上司这些问题?老实说,这将是你最好的方法。
哪种方法更好?
都不是。它们代表着相同的功能数据量。你必须回答的问题如下:
审计字段通常不经常被查询,只在您必须重构事件时才被引用。这两种方法对于预期的用例都可以很好地工作。
发布于 2018-05-25 19:51:05
这里已经有了很好的答案,但让我回应一下你的“非无效”论点:
我们要确保这不会因为任何错误而被空置。
当更新发生时,允许这些字段为空的错误与在发生更新时忘记将字段更新为正确值的可能性差不多,因此此参数是一个逻辑谬误。
如果created_at和updated_at字段具有相同的值,则可以很容易地确定记录是新的。
当然,但是测试NULL既不困难,也不容易。好的,在某些情况下,我们必须特别注意查询中的NULL,但这几乎不是一个足够重要的差别,以至于通常禁止空列。
处理这些更新字段的代码将更干净,因为它不需要检查它们是否为空。
这在很大程度上取决于所使用的语言和db框架,但老实说,空值支持并不是一门科学,也不应该使代码变得更加复杂。
其他在工作的团队也遇到了不便。有些处理数据的工具不兼容,或者不能正常工作,而条目的值为空更新。
那么,您是说还有其他团队有问题要正确处理空值吗?我是认真的?如果它们确实有一些工具存在问题,那么这些工具如何处理其他表中的NULLable列?我相信你没有一个公司范围的规则禁止这样的列(否则你一开始就不会问这个问题),所以它们最好修正那些工具,因为它们迟早要处理空值。
简而言之,你(可能也是你的上级)过度考虑这个问题,这两种方法都同样有效,你能做的最好的事情就是抛硬币。
发布于 2018-05-25 18:25:12
这两种方法都是可行的,这两种方法都没有本质上的问题。我倾向于使用您所提倡的方法,主要是因为由于三值逻辑,在SQL中使用空值是一件很痛苦的事情。一般来说,最好是避开它们。正如您所说的,updated = created告诉您,对于新记录而言,使用更新的字段be null是一样的。
另外,这方面的总体设计可以改进。在这种方法中,您可以看到记录是什么时候创建的,以及最后一次更新的时间。您无法知道在此过程中还可能在什么时候修改了它,或者每个步骤中的值是什么。一种更稳健的方法是使用只插入的方法。在这种情况下,您只跟踪创建的时间戳。那么你就有了所有这些变化的全部历史。对于只需要当前数据的客户端,可以使用此表上的视图进行简化。
https://softwareengineering.stackexchange.com/questions/371570
复制相似问题