Reference vs multi-reference

Both a reference and a multi-reference link an entry to entries in another collection, and both store a link rather than a copy of the target. The only difference is how many targets one entry can hold: a reference holds exactly one, a multi-reference holds several. Everything below follows from that one distinction.

Reference — exactly one target

Reach for a reference when an entry connects to a single other entry. A deal belongs to one company; a contact has one employer; a booking has one customer. "One" is about each entry, not the whole collection — many deals can point to the same company. That many-to-one shape is still a reference: the link lives on the many side (the deal), and the one side (the company) reads its deals back through a rollup or lookup. If you catch yourself adding a multi-reference to hold "all the deals of this company," stop — that link belongs on the deal.

Multi-reference — several targets at once

Reach for a multi-reference when a single entry genuinely holds several links at the same time. A project with several collaborators, a service delivered at several locations, an entry tagged with several other records — each is one entry pointing at many. The test: can this one entry have more than one of these at the same moment? If yes, and they are peers with no single primary, a multi-reference fits.

What each costs

• A multi-reference blurs which one is primary. It treats all targets as equal members. If one is special — a primary contact, a main location — a flat multi-reference cannot say so on its own. That is a signal to use a single reference for the primary and handle the rest separately.
• A reference on the wrong side forces awkward edits. Putting the link on the one side (a company holding a multi-reference of its deals) means editing the company every time a deal is added. Putting it on the many side (each deal referencing its company) keeps every edit local. Model many-to-one on the many side.
• Neither can point at its own collection. A reference and a multi-reference must target a different collection. For a self-recursive link — a company and its parent company, a category nested under a category — use a parent instead. That is what parent is for.
• The choice is not cheap to undo. A field's type is fixed once you create it; switching a reference to a multi-reference later means adding a new field and migrating the data, not flipping a setting. Pick for the real cardinality up front.

Rule of thumb

Ask how many one entry can have. One → reference. Several at once → multi-reference. Another row in this same collection → parent, not either of these.