Is there a design pattern for merging duplicate database records?

Question

For example, let's say I had a social networking site for movie fans. Some people list "Rocky" as their favorite movie, others list "Rocky 1", other still "Rocky I". The obvious thing is to merge the three together and update the associated tables. However, for every obvious solution there's a design pattern that's 1) more complicated and 2) has some extra benefits. Is there a design pattern for merging duplicate database records? Specifically, something that provides auditability or reversibility?

Answer 1

As soon as you as you say "reversibility" I think Command Pattern.

The typical example is to support Undo style behaviour but I think this would be a good fit for auditability as well - especially as the individual "steps" (for want of a better word) are so small and easily represented (e.g. {Merged "Rocky I" -> "Rocky" }).

How would I get the Command pattern to actually work for your scenario?

Well, keeping this very much in the RDBMS arena rather than OO modelling, assuming you've already got tables USER_FAVORITE and MOVIE, I'd add a new table USER_FAVORITE_MOVIE_MERGE_COMMAND with columns:

• id
• date
• user_id
• old_favorite_movie_title
• new_favorite_movie_title

So your nightly cleanup script (or whatever) runs over the USER_FAVORITE table looking for non-standard movie titles. Each time it finds one, it corrects it and records the pertinent facts in the USER_FAVORITE_MOVIE_MERGE_COMMAND table.

Your audit trail is right there, and if you ever need to reverse the cleanup job, "play back" the rows in reverse chronological order, replacing new with old.

Notice how you've got both reversibility and auditability both in the temporal sense (e.g. last night's batch run went weird at 2.12am, let's roll back all the work done after that) and in the per-user sense.

Is this the sort of thing you're after?