A collection app can make a frustrating mistake: it finds the same movie title twice and refuses the second entry. That rule prevents some accidental duplication, but it also rejects legitimate cases such as another edition, a replacement copy, or a film already included in a box set.
The design problem is not simply detecting matching strings. It is distinguishing the entities involved and explaining what the match means. Here is a conceptual design for a personal disc collection, without assuming a particular implementation stack.
Separate works, editions, and physical copies
A work represents the film or series being cataloged. An edition represents a particular release or package. A physical copy represents one item owned by the user. Two copies may refer to the same edition, while two editions may contain the same work.
Collections add another relationship: one edition can contain several works. Store those contents as relationships rather than stuffing a list into the edition's display title. If cuts matter to the application, represent the named version explicitly within the release contents instead of silently treating every appearance of a work as identical.
Give each entity a stable internal identifier. A barcode or catalog number can help identify an edition, but it should not serve as the identity of a particular physical copy. Buying two identical packages is a valid scenario.
Decide what kind of duplicate you are detecting
An accidental repeat submission is different from an intentional second copy. The first is a workflow problem: the user presses Save twice while the response is slow. The second is a collection fact: there really are two items.
Handle repeated submissions with an operation identifier and an idempotent save contract. The server should recognize a retry of the same operation and return its existing result. If it uses a database, enforce the operation identifier's uniqueness atomically rather than relying on a separate check followed by an insert.
Do not reuse a title-uniqueness rule to solve that problem. An intentional new copy needs a new operation and a new copy record, even when the edition is unchanged. The operation identifier identifies the request, not the movie.
Generate candidates, then classify the evidence
Start with strong matches such as a known edition identifier. Next consider verified work relationships, including titles inside an owned collection. Title normalization can produce additional candidates, but those candidates need review.
Whitespace and case normalization may help search. Aggressive punctuation removal or fuzzy title matching can also bring unrelated entries together, so do not let a similarity score silently merge records. Remakes, alternate titles, and missing release years are reasons to show uncertainty.
A candidate can be described as “same edition,” “same work in another edition,” or “possible title match.” Each label should follow from available evidence. Missing edition information should produce a weaker claim, not a guessed match.
Write warnings that support a decision
For a confirmed edition match, a warning might say: “You have one copy of this edition on Shelf B. Add another copy?” Offer actions to view the existing record, add another copy, or cancel.
For a work found inside a box set, say where it was found. “This film is listed in your Collection C014” gives the user something to verify. A vague “Duplicate detected” does not explain whether the edition or only the underlying work matches.
For a possible title match, show the fields that need comparison, such as work year, format, and release notes. Keep the user's entered values intact while they inspect the candidate. Dismissing the warning should not erase the draft.
Make status part of the warning
A loaned copy is still owned, so it should remain visible in a duplicate check. An ordered item is not yet a physical copy in hand, but it can still justify an “already ordered” warning. A wish-list entry should not be counted as owned.
Model acquisition intent separately from confirmed possession if the application's scope allows it. When an order arrives, connect the received copy to the order rather than leaving two unrelated records that both appear to represent ownership.
Likewise, a disposed or lost item should not produce an unqualified “on your shelf” message. Use the current status in the explanation and let the user inspect the history when relevant.
Check the cases that reveal incorrect assumptions
Useful acceptance scenarios include two physical copies of one edition, two editions of one work, a film contained in a multi-film package, and two different films with similar titles. Include a missing-year case that produces a review prompt rather than an automatic merge.
Also check that a retried save creates one copy, while a deliberate second-copy operation creates two. A loaned item should remain searchable, an incoming order should have its own wording, and a wish-list match should never be reported as confirmed ownership.
Our DVDWholesaleShop US catalog provides the retail context for these examples. It is our store, not a claim that this collection system is implemented there or that every listing supplies all the identifiers the proposed model needs.
Good duplicate handling prevents accidental actions while preserving legitimate choices. The warning earns trust by explaining the match and allowing the collector to decide what that match means.
Top comments (0)