由于初始设计不佳，许多重复已经悄悄进入客户的数据库。我正在编写一些存储过程来合并用户等。完成合并并且仍然能够执行撤消或回滚而不执行完整数据库还原会很好。
我最初的问题是我需要做多少其他家务或记录保存，我该怎么做？我想我已经解决了这个问题。现在的问题是，是否还有以下任何事情需要做。我意识到这对于这个网站来说这是一个很糟糕的问题。为了补偿这一点，我建议与任何需要构建重复记录合并工具的人分享我的经验。
合并的基本伪代码是：
设from_id =要合并的记录（合并）。设into_id =合并后所有from_id引用需要指向的记录。
根据已知参数检查数据库架构，如果更改则返回schema_changed错误。
使用merge_config和merge_referrer_config表中的信息向merge_log和merge_referrer_log表添加条目，以提供有关需要更改以完成合并的每个数据的详细说明。此日志成为回滚（撤消）的说明。配置表提供有关数据库中引用合并记录的所有位置的完整信息。
按照刚刚添加到合并日志表中的说明更新所有相关的（在merge_config和merge_referrer_config表中定义）表，以设置相关列= into_id，其中相关列= from_id。
将from_id的记录的merged_to列标记为into_id。
谢谢， 汤姆
答案 0 :(得分：1)
嗯，无论如何你应该做一些备份，以防出现可怕的错误。
就审计线索而言，我会受到重复表的诱惑，当它被“合并”时会有一个额外的列，然后就是保留它。在合并运行之前，从重复项中删除任何超过X old的东西。我见过的另一个选择是加权记录的差异。 “完全重复”是0所有不同但关键是100。然后根据权重查克/保持。
无论你采取什么样的方法，在你开始审核每一个嗅探的基础上看一下，然后当你“了解”数据时，你可以默默地将它包装起来，或者看看优先考虑中的关键弱点。系统