design-patterns - 是否有合并重复数据库记录的设计模式？

Question

例如，假设我有一个供影迷使用的社交网站。有些人将“Rocky”列为他们最喜欢的电影，其他人将“Rocky 1”列为“Rocky 1”，其他人仍然是“Rocky I”。显而易见的是将三者合并在一起并更新关联的表。然而，对于每个明显的解决方案，都有一个设计模式，它 1) 更复杂，2) 有一些额外的好处。是否有合并重复数据库记录的设计模式？具体来说，提供可审计性或可逆性的东西？

Answer 1

只要你说“可逆性”，我就想Command图案。

典型的例子是支持撤消风格的行为，但我认为这也非常适合可审计性 - 特别是因为单个“步骤”(因为想要一个更好的词)非常小且易于表示(例如 {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中。 table 。

您的审计跟踪就在那里，如果您需要反转清理工作，请按时间倒序“回放”行，替换 new与 old .

请注意如何在 中同时获得可逆性和可审计性。时间 感觉(例如，昨晚的批处理运行在凌晨 2.12 变得奇怪，让我们回滚之后完成的所有工作)和 每个用户 感觉。

这是你追求的那种东西吗？