CDS Associations vs Joins and When Each Fires

A join inside a CDS view entity is resolved when the view is activated: the database has to combine the tables every time that view is read, whether or not the joined columns end up in the final result. An association is different. It is a named, typed relationship declared with a cardinality and an ON condition, but it produces no SQL by itself. It only turns into a real join at the moment some consumer writes a path expression against it, filters with an exists predicate that references it, or an OData client asks for an expand on it. If nothing ever touches the association, the view runs exactly as if the association were not declared. The confusion almost always comes from treating the two as interchangeable syntax for 'related data' when only one of them is evaluated eagerly and the other is evaluated on demand, sometimes several view layers away from where it was declared.

Use a join when the combined data is genuinely required on every read of that view, for example a sales order line that always needs its plant and material description flattened into the result for a report that never runs without them. Use an association when the related data is optional, consumer-specific, or only needed for drill-down, filtering, or expand: business partner address details on an object page, a status text only some consumers display, or a parent-child hierarchy navigated occasionally. Reaching for a join out of habit when the field is rarely selected is the mistake that inflates every query against that view. Reaching for an association when every single consumer needs the field anyway just defers work that will fire on every call regardless, adding a layer of indirection with no benefit.

Below both sits the physical or virtual data source: database tables, other CDS view entities, or a table function. A join operates within one view definition and is fixed there for every consumer of that view. An association sits above that same layer but is published outward: a consuming CDS view, a RAP behavior definition, or an OData service can extend the path further, filter through it with exists, or request it as an expand without the publishing view having to pre-join anything. Associations are what make CDS view composition and RAP business object composition workable at scale, because each layer only declares relationships rather than paying for them. Classic ABAP Open SQL joins and nested SELECTs are what associations and CDS joins together are meant to replace; associations specifically replace the pattern of building several near-identical flat views just to expose different combinations of joined fields.

A sales order header CDS view entity declares an association to business partner, cardinality to-one, ON condition matching the sold-to party. A Fiori elements list report consumes that header view for the list screen and only selects order number, date, and status; the association is never touched in the list query, so no join to business partner runs and the list query stays cheap regardless of table size. The same view is consumed by the object page, where the UI annotation exposes the association for expand; the moment a user opens a single order, the OData request navigates the association and the framework generates the join at that point, scoped to one order key. Contrast this with an earlier version of the same view that joined business partner directly into the header select: the list report query would then always carry that join, even though the list screen never displayed a partner field, and the extra cost would show up in the list report's response time as the order table grew, not in the object page where the data was actually needed.

Association-based composition is the pattern S/4HANA and clean core guidance actively favor: build narrow, reusable CDS view entities connected by associations rather than wide flat views stitched together with joins and nested selects against transparent tables. RAP business object composition assumes associations as the mechanism for reaching child and related entities, and Fiori elements relies on published associations for expand behavior on object pages. Classic ABAP joins against database tables directly, and older DDIC views that flatten multiple tables permanently, are the pattern this approach is meant to move away from, particularly where extensibility or reuse across several apps is expected. No specific release restricts either construct; the shift is architectural guidance, not a version gate.

This is developer territory at the point of writing the CDS view, but the decision of which associations get published for expand or exists usage is an architectural call, because it determines what downstream consumers, including RAP behavior implementations and Fiori apps, are allowed to reach. Handover to functional teams should identify which associations carry cardinality risk if used without exists.

Read cds-view-entities-versus-classic-cds-ddic-views for the container these associations live in, performance-of-nested-cds-views for what happens when several layers of associations and joins are stacked, and rap-business-object-composition for how associations underpin parent-child navigation in RAP. odata-query-options-and-server-side-paging is worth checking when an expand triggers an association-driven join that changes result cardinality unexpectedly.