由于初始设计不佳，客户端数据库中出现了大量重复。我正在编写一些存储过程来合并用户等。如果完成合并，并且仍然能够在不进行完整数据库还原的情况下执行撤消或回滚，那就太好了。
我最初的问题是我需要做多少其他的家务或记录，我该怎么做?我想我已经说过了。现在的问题是，除了以下这些，是否还有其他事情需要做。我现在意识到这对这个网站来说是一个糟糕的问题。作为补偿，我愿意与任何需要构建重复记录合并工具的人分享我的经验。
合并的基本伪代码是:让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
用into_id标记from_id记录的merged_to列
谢谢,汤姆
无论如何你都应该做一个备份，以防出现严重的错误。
在审计跟踪方面，我会被一个重复表所吸引，当它被"合并"出来时，会有一个额外的列，然后保留它。例如，在合并运行之前，从副本中删除任何超过X岁的内容。我看到的另一种选择是对记录的不同程度进行加权。"完全复制"是0，所有东西都不一样，但密钥是100。然后根据权重进行卡盘/保留。
无论您采用何种方法，在开始时审计每个嗅探的基础上查看它，然后当"您"对数据有了感觉时，您可以默默地将其保存，或者查看系统中关键弱点的优先级