This blog post provides perspective on when to store data inline, within a single entry in the content management system, and when to store some of that data in separate entries. If you have perspectives on this topic, please comment on this blog post.
The first time that I started writing this blog post, I ended up writing the following two blog posts that I recommend reading or at least scanning for some context. If you are not familiar with these topics, you may also want to follow the links in these posts:
- https://deliverystack.net/2022/03/08/when-to-use-group-reference-global-and-modular-blocks-fields-in-the-contentstack-saas-content-platform/
- https://deliverystack.net/2022/03/09/reusing-modular-blocks-with-the-contentstack-saas-content-platform/
This is another relevant post.
Also, this seems worth repeating here: for search engine optimization (SEO) of web solutions, an individual piece of content should appear at a single URL. In most cases, content reuse within a web solution does not involve the primary content of an entry or page, but peripheral elements such as promotions, calls to action, presentation components, and other reusable aspects of visitor experience management rather than the main page content body.
For minimal context: an entry is a record in the CMS, where the content type of the entry specifies fields that define its structure. Using reference fields, rich text fields, and other features, all CMS allow entries to reference other entries. Most CMS support flat lists of fields, but some allow nested fields, which facilitates a greater number of fields in a single entry. CMS that do not support nested fields can use custom fields to manage similar complex structures.
For simplicity, usability, and developer productivity, I would avoid references in favor of managing content, presentation configuration, and almost any other data inline whenever possible. I would evaluate references when some number of the following conditions hold true:
- The entities to model are logically distinct rather than describing a single concept. For example, information about the author of an entry typically belongs in a separate referenced entry.
- The entries to reuse already exists but extending their content types with new fields is not appropriate.
- The data to reference has no logical parent entry.
- Storing the data inline would result in usability challenges such as an excessive number of fields.
- The data must be reusable and there is no other mechanism for its reuse.
- There are advantages to managing separate entries (lock, edit, version, translate, workflow, publish, delete, and so forth).
For efficiency when retrieving an entry, developers can pass parameters that cause the CMS to inline data from the referenced entries into the referencing entries rather than retrieving referenced entries separately afterwards.
Deliverystack.net 