例如，假设我有一个电影迷的社交网站。有些人将“Rocky”列为他们最喜欢的电影，其他人列出“Rocky 1”，其他人仍然是“Rocky I”。显而易见的是将三者合并在一起并更新关联的表。但是，对于每个明显的解决方案，都有一种设计模式，即1）更复杂，2）有一些额外的好处。是否有用于合并重复数据库记录的设计模式？特别是，提供可审计性或可逆性的东西？
答案 0 :(得分：5)
当你说“可逆性”时，我认为Command模式。
典型的例子是支持撤销样式行为，但我认为这也非常适合可审计性 - 特别是因为个别“步骤”（因为缺少更好的词）是如此之小且易于表示（例如{ {1}}）。
如何为您的方案获取命令模式实际工作？
好吧，假设你已经有了表{Merged "Rocky I" -> "Rocky" }和USER_FAVORITE，那么在RDBMS领域而不是OO建模中保持这一点，我会添加一个新的表MOVIE列：
USER_FAVORITE_MOVIE_MERGE_COMMAND id date user_id old_favorite_movie_title 所以你的夜间清理脚本（或其他）在new_favorite_movie_title表上运行，寻找非标准的电影标题。每次找到一个时，它都会对其进行更正，并在USER_FAVORITE表中记录相关事实。
您的审计跟踪就在那里，如果您需要撤销清理工作，请按相反的时间顺序“回放”行，将USER_FAVORITE_MOVIE_MERGE_COMMAND替换为new。
请注意你是如何在时间意义上获得可逆性和可审计性的（例如，昨晚的批次运行在上午2点22分变得奇怪，让我们回滚所有工作之后完成和 per-user 意义。
这是你想要的事吗？