A catalog starts with one movie table and one runtime field. Then a product arrives containing two cuts of the same film. Which runtime should the product page display, and which one should a movie-night planner use?
The title alone no longer identifies the thing being timed. A useful model separates the work, its cuts, the presentations of those cuts, and the releases that contain them. This is a conceptual design proposal, not a description of a feature implemented in our store.
Give the work a stable identity
The work record identifies the film: its catalog ID, title, and disambiguating metadata such as the original release year. Avoid using a title string as the key. Remakes and unrelated films can share a name.
A cut references that work and identifies an edited version. Store a display label, relevant version date or territory when known, and supporting editorial notes. “Theatrical” may be too broad to uniquely identify a version, so do not make that label globally unique.
Treat runtime as a contextual value
Moving runtime off the work record is the first improvement. A cut can carry a documented reference duration, but an exact playback duration may depend on its presentation. Technical playback differences, rounding, and the measurement boundary can make two reported values look inconsistent without proving the edits differ.
For this design, a presentation references a cut and holds its measured or stated duration. Record the unit, source, precision, and measurement basis. A rounded distributor figure in minutes should not become a falsely precise seconds value in the interface.
Unknown is not zero. Do not fill a missing presentation duration with the work's old number just to keep a card looking complete. If a fallback is useful, label it as a reference estimate and retain its source.
Let a release contain more than one presentation
A physical release is the product-level package. Link it to the feature presentations it includes, rather than making every product point to exactly one cut. A release containing two cuts then has two feature entries, each with its own label and duration information.
Keep supplements separate from feature presentations. A collection of deleted scenes is not automatically another cut, and the sum of a feature and its extras is not a feature runtime.
Use stable keys and referential constraints for these relationships. PostgreSQL's documentation explains how primary and foreign keys express row identity and valid references. The editorial meaning of a cut still needs a catalog policy; a database constraint cannot decide whether two releases contain the same edit.
Model where a feature can be accessed
A product may describe physical content and another form of access. Give the inclusion relationship an access type so a disc-only filter does not silently count an offer that is not on the disc.
For a physical presentation, optional location information can identify the disc and menu label when verified. Do not derive disc numbers from list order. An editor reordering a product description must not change where the catalog claims a feature can be found.
Make the display follow the selected version
A multi-cut product page can show a labelled list instead of one unexplained runtime: “Theatrical version — duration confirmed” and “Extended version — duration not confirmed,” for example. Use actual values only when the data supports them.
A planner should require a cut or presentation choice before treating the runtime as exact. If the user has not chosen, show that the duration depends on the version. Sorting on a single number without explaining the rule can put unlike products into a misleading order.
Audio and subtitle details also need an appropriate scope. Do not copy one presentation's features onto every cut in the package merely because they share a product ID.
Preserve disagreement instead of overwriting it
Suppose a publisher description and a measured disc duration disagree. Retain both observations with their source and basis, then let a reviewed display value resolve the user-facing question. A new import should not erase the evidence behind an earlier value.
Ask whether the records refer to the same cut, presentation, and measurement boundary before treating one as wrong. Duration is useful evidence, but it is not a reliable identity key: different edits can have similar lengths.
Review cases that a flat table hides
Check a release with two cuts, one cut across multiple formats, unknown duration, rounded duration, separately listed deleted scenes, and a feature available through a non-disc offer. Confirm that choosing a version updates the planner without changing another version's data.
Our DVDWholesaleShop catalog supplies the domain context for this hypothetical design. The broader modeling lesson is to attach a fact to the entity and context it actually describes. A convenient field on a title record should not become a claim about every version a customer might receive.
Top comments (0)