例如，假设我有一个面向电影迷的社交网站。一些人将“ Rocky”列为他们最喜欢的电影，其他人将“ Rocky 1”列为其他，而其他人仍将其列为“ Rocky I”。很明显的事情是将三个合并在一起并更新关联的表。但是，对于每个显而易见的解决方案，都有一种设计模式，即1）更复杂，2）具有一些额外的好处。是否有用于合并重复数据库记录的设计模式？具体来说，是否提供可审核性或可逆性？
最佳答案
只要您说“可逆性”，我就会想到Command模式。
典型的示例是支持撤消样式行为，但是我认为这也非常适合于可审核性-尤其是因为单个“步骤”（由于缺少更好的用词）非常小且易于表示（例如{Merged "Rocky I" -> "Rocky" }） 。
如何获得适用于您的方案的Command模式？
好吧，假设您已经拥有表USER_FAVORITE和MOVIE，则将其保留在RDBMS领域而不是OO建模中，我将添加带有列的新表USER_FAVORITE_MOVIE_MERGE_COMMAND：iddateuser_idold_favorite_movie_titlenew_favorite_movie_title
因此，您的夜间清理脚本（或其他任何脚本）在USER_FAVORITE表上运行，以查找非标准的电影标题。每次找到一个，它都会对其进行更正并将相关事实记录在USER_FAVORITE_MOVIE_MERGE_COMMAND表中。
您的审核跟踪就在那儿，如果您需要撤消清理作业，请以相反的时间顺序“播放”行，将new替换为old。
请注意，在时间意义上（例如，昨晚的批处理运行在2.12am变得很奇怪，让我们回退此后完成的所有工作）在时间意义上既具有可逆性又具有可审计性。
这是您所追求的吗？