【问题标题】:Validation between two tables having conversion logic between them两个表之间的验证,它们之间有转换逻辑
【发布时间】:2021-08-28 14:33:21
【问题描述】:

有 2 个表需要进行比较。

可能存在数十万条数据,因此无法进行手动验证。

验证是通过一个工具来完成的,该工具比较两个表中每个主键 (ID) 的对应列

列名 - ID(主键)、TYPE(允许值 P 或 O)、出生日期、成立日期

P 表示人,O 表示组织 如果 type = P,则 dob 值将存在并且基础日期将为空 如果 type = O,则 dob 将为 null 并且将存在基础日期值

例子

Table 1:
(1,P,1972-08-09,null)
(2,O,null,1994-05-04)
(3,P,1995-08-09,null)
(4,O,null,1990-07-06)

Table 2:

(1,P,1972-08-09,null)
(2,O,null,1994-05-06)
(3,P,1995-07-19,null)
(4,O,null,1990-07-06)

对于上述示例,记录号 2 和 3 不匹配,应报告。

现在,这两个表之间存在转换逻辑,因此很少有当事方记录转换为组织,反之亦然。

在下面的示例中,记录 1 从 P 转换为 O:

Table 1:
(1,P,1972-08-09,null)
(2,O,null,1994-05-04)
(3,P,1995-08-09,null)
(4,O,null,1990-07-06)

Table 2:
(1,O,null,1972-08-09)
(2,O,null,1994-05-04)
(3,P,1995-08-09,null)
(4,O,null,1990-07-06)

由于这种转换,存储在 dob 中的值存储在基础日期中,并且 dob 设置为 null,反之亦然。

现在,当我们将这些表与我们拥有的工具进行比较时,它会将记录 1 显示为不匹配。

但是,如果我们仅针对记录 1 对表运行 2 个单独的查询并手动验证数据,我们可以说这不是问题。

现在,想象一下这种情况,有成千上万的数据不匹配。

请记住,这些不匹配可能是真实的,如示例 1 所示,也可能只是由于转换逻辑,如案例 2 所示。

第一种类型可以通过运行该工具两次来识别,一次仅用于P,另一次仅用于O。

但是对于第二种类型,我们使用采样技术并手动检查 5-6 个数据(即使有数千或数十万个不匹配),如果正确填充了这 5-6 个数据,我们假设所有这些都没有问题

能否以更好的方式实施整个验证?

【问题讨论】:

  • 我删除了不一致的数据库标签。请仅使用您真正使用的数据库进行标记。

标签: sql


【解决方案1】:

只需合并每条记录中的 2 个日期字段,然后在 PK 上加入表时比较表之间的合并值

【讨论】:

    猜你喜欢
    • 2020-03-07
    • 2015-09-11
    • 1970-01-01
    • 1970-01-01
    • 2016-04-09
    • 1970-01-01
    • 1970-01-01
    • 2015-01-12
    • 2019-11-21
    相关资源
    最近更新 更多