系统

在以客户为中心的系统中，Customer_id是带有7个前导空格的右对齐9位代码。有效条目为“ 000000399”。

有一个主CUSTOMERS表和近80个明细表。主表CUSTOMERS每个Customer_id都有多个记录，并使用Start_date，End_date列作为记录历史记录。 End_date最初是'9999'，并且在插入现有Start_date的新记录时更新为新记录的Customer_id。

下面是一个示例。 Customer_id'000000399'的第一条记录为：

+ -------------------- + --------------------- + --- ------------------ + | Cust_id |开始日期|结束日期| + -------------------- + --------------------- + ------ --------------- + | '000000399'| '20100225210300000'| '9999'| + -------------------- + --------------------- + ------ --------------- +

让我们假设在2010-03-03 12:37:33,000处插入了一条新记录。新记录的End_date应该为'9999'，而前一条记录的End_date应该用新的Start_date更新。该Customer_id的记录应为：

+ -------------------- + --------------------- + --- ------------------ + | Cust_id |开始日期|结束日期| + -------------------- + --------------------- + ------ --------------- + | '000000399'| '20100225210300000'| '20100303123733000'| | '000000399'| '20100303123733000'| '9999'| + -------------------- + --------------------- + ------ --------------- +

在使用Start_date和End_date列的主表和明细表中遵循此模式。

问题在某个时间点Customer_ids开始以错误的格式插入。您可以为同一位客户找到以下格式。

'       000000399'

'000000399       '

' 000000399      '

问题在于这些Customer_ids被视为系统中不同的客户，因此它们维护着自己的Start_date和End_date链。我们最终获得了以下客户记录（按Start_date排序）。

+---------+-------------+-------------------+-------------------+-------------------+
| Cust_id | New_Cust_id | Start_date        | End_date          | New_End_date      |
+---------+-------------+-------------------+-------------------+-------------------+
| 399     |             | 20100225210300000 | 20100303123733000 |                   |
+---------+-------------+-------------------+-------------------+-------------------+
| 399     |             | 20100303123733000 | 20110127001826000 |                   |
+---------+-------------+-------------------+-------------------+-------------------+
| 399     |             | 20110127001826000 | 20110129001706000 |                   |
+---------+-------------+-------------------+-------------------+-------------------+
| 399     |             | 20110129001706000 | 20120309001920000 |                   |
+---------+-------------+-------------------+-------------------+-------------------+
| 399     |             | 20120309001920000 | 20120406001926000 |                   |
+---------+-------------+-------------------+-------------------+-------------------+
| 399     |             | 20120406001926000 | 20120524001910000 |                   |
+---------+-------------+-------------------+-------------------+-------------------+
| 399     |             | 20120524001910000 | 20130129180350000 |                   |
+---------+-------------+-------------------+-------------------+-------------------+
| 399     |             | 20130129180350000 | 20131212153024000 |                   |
+---------+-------------+-------------------+-------------------+-------------------+
| 399     |             | 20131212153024000 | 20150424184238000 |                   |
+---------+-------------+-------------------+-------------------+-------------------+
| 399     |             | 20150424184238000 | 20160222184547000 | 20151103095530339 |
+---------+-------------+-------------------+-------------------+-------------------+
| 399     | 399         | 20151103095530339 | 20180714105242000 | 20160222184547000 |
+---------+-------------+-------------------+-------------------+-------------------+
| 399     |             | 20160222184547000 | 20180911143426000 | 20180714105242000 |
+---------+-------------+-------------------+-------------------+-------------------+
| 399     | 399         | 20180714105242000 | 9999              | 20180911143426000 |
+---------+-------------+-------------------+-------------------+-------------------+
| 399     |             | 20180911143426000 | 9999              |                   |
+---------+-------------+-------------------+-------------------+-------------------+

挑战

我们面临着清理数据的挑战，以确保没有Customer_ids偏差，并且当前数据保持其完整性和一致性。在上面的示例中，解决方案是将错误的Customer_ids插入正确位置（Start_date/End_date）并使用正确的Customer_id格式的记录。让我们为需要更新的列添加一些新列。

+---------+-------------+-------------------+-------------------+-------------------+
| Cust_id | New_Cust_id | Start_date        | End_date          | New_End_date      |
+---------+-------------+-------------------+-------------------+-------------------+
| 399     |             | 20100225210300000 | 20100303123733000 |                   |
+---------+-------------+-------------------+-------------------+-------------------+
| 399     |             | 20100303123733000 | 20110127001826000 |                   |
+---------+-------------+-------------------+-------------------+-------------------+
| 399     |             | 20110127001826000 | 20110129001706000 |                   |
+---------+-------------+-------------------+-------------------+-------------------+
| 399     |             | 20110129001706000 | 20120309001920000 |                   |
+---------+-------------+-------------------+-------------------+-------------------+
| 399     |             | 20120309001920000 | 20120406001926000 |                   |
+---------+-------------+-------------------+-------------------+-------------------+
| 399     |             | 20120406001926000 | 20120524001910000 |                   |
+---------+-------------+-------------------+-------------------+-------------------+
| 399     |             | 20120524001910000 | 20130129180350000 |                   |
+---------+-------------+-------------------+-------------------+-------------------+
| 399     |             | 20130129180350000 | 20131212153024000 |                   |
+---------+-------------+-------------------+-------------------+-------------------+
| 399     |             | 20131212153024000 | 20150424184238000 |                   |
+---------+-------------+-------------------+-------------------+-------------------+
| 399     |             | 20150424184238000 | 20160222184547000 | 20151103095530339 |
+---------+-------------+-------------------+-------------------+-------------------+
| 399     | 399         | 20151103095530339 | 20180714105242000 | 20160222184547000 |
+---------+-------------+-------------------+-------------------+-------------------+
| 399     |             | 20160222184547000 | 20180911143426000 | 20180714105242000 |
+---------+-------------+-------------------+-------------------+-------------------+
| 399     | 399         | 20180714105242000 | 9999              | 20180911143426000 |
+---------+-------------+-------------------+-------------------+-------------------+
| 399     |             | 20180911143426000 | 9999              |                   |
+---------+-------------+-------------------+-------------------+-------------------+

一张图像算上一千个单词，所以它应该是这样的： records injected in between

简而言之，只要随后的记录具有不同的Customer_id格式，就必须将先前记录的结束日期更新为插入的Start_date的值。当然，错误的Customer_id也必须更新为正确的格式（正确对齐）。

因此，先前数据的最终状态应类似于： records updated as needed 更新的数据以绿色显示。

解决方案

我正在寻找一种清理数据的方法。我有一些初步想法，但我想听听一些建议。数据库的索引最少，大多数表都是堆，没有引用键。一些数字： -32M客户记录 -4M独特的Customer_ids -150K错误记录（错误的Customer_id格式） -80张记录有误的桌子 -132M条记录是最大的表

局限性 -停机时间最少 -新记录即将进入数据库（希望格式正确）

我目前正在编写一个程序，该程序将执行以下操作：

从Customer_id表中选择每个有错误记录的不同CUSTOMERS。
开始新交易

a。创建一个包含所有相应记录的临时表表CUSTOMERS的{{1}}（所有格式）
- i。根据以下内容对临时表上的这些记录进行排序开始日期
- iii。更新错误的Customer_id
- iv。更新Customer_id表上更改的记录-通过删除所有相关记录并从临时表，或者-通过更新现有的相关记录
b。继续到下一个（详细）表并创建一个新的临时表一世。重复步骤i-iv
在所有80个明细表中更新当前CUSTOMERS的记录时，提交事务。
转到下一个Customer_id，然后重复步骤1-3
祈祷一切都会按计划进行...

请分享您的想法。

PS。抱歉，冗长的帖子：）

如何清除数据库中多个表中的数据？

系统

挑战

解决方案

0 个答案: